241–250 of 392 posts
[flagged]
We detached this subthread from https://news.ycombinator.com/item?id=13145121 and marked it off-topic.
Maybe you don't agree? I guess that's your right as one of the moderators...
I really am starting to wonder if you are seeing a different XKCD comic to me, or maybe I'm being gas lighted by HN.
I think the problem for me is that they did these changes and made a big song and dance about Python 3. If they had have called Python 3.0 v2.9 instead everyone would have been clear they had to migrate. PHP has been successfully deprecating features for decades now and cleaned up their code base; they have never had a schism in the way Python has so you can argue all you want about legacy, or people preferring 2.7.…
> If they had have called Python 3.0 v2.9 instead everyone would have been clear they had to migrate. [...] The reason this happend (and is still happening) are human not technical. You know, as a strong proponent of Python 3.* (it's a significantly better Python), I started to write a withering critique of your statements here (and I do strongly disagree about naming it Python v2.9). But then I started actually look…
The idea that Python 2 needs to be sabotaged and the community forbidden from improving it so that people makes the move, with the people who are stuck to Python 2 codebases held as hostages, should be an indicator that something was done very, very wrong...
Personally, I'm neutral as to 2 vs. 3, I use both, but the schism is the main drawback of Python for me and it often drives me to just use other languages. Python 3 is great and has very neat improvements, but it should have just been called a different name so that both branches could evolve freely and compete on their own merits, rather than on the PSF mandating to use one over the other.
As others have said, maybe this project fixes some actual problems and backports some features from 3, but this isn't "Python". Beyond the fact that Python is a trademark of the Python Software Foundation, Python is more than the language, it's the community and the tools (as with every programming language). So while there are some vocal people that really dislike Python 3 (either in part or wholly), my understandin…
Why isn't it a valid Python compiler?
To me, the whole morass about trying to end-of-life Python 2 is a bit silly. People have gotten emotional about the situation.
On one side, people like Zed Shaw are calling the Python maintainers 'evil' and claiming conspiracy.
On the other side, people are calling companies using Python 2, 'lazy' and claim they're a threat to the ecosystem.
Yet elsewhere, C is still being written in all of its various year-specific formats, and people end up using 'old' versions simply because they join pre-existing projects or need to totally interface with something that's written in an 'old' version.
Python is an extablished language, it's likely that 10 years from now there will still be Python 2 codebases going strong.
Earlier quoted context omitted.
This argument is a reasonable one and is why we all support IE6 for web dev. However, at a certain point it is worth your time to move forward instead of doing nothing, you gain a little time savings now and you run into few moments of "Oh @#$%^!!" later. Real world example: You don't bother updating ssl to deal with weak DHE and suddenly chrome users can't see your payment site. My approach has always been to try to…
Except Python 3.x is bringing controversial changes and was slower than Python 2.x for several years. If IE7 was slower than IE6, you can't blame people to not move over.
There are however non backwards compatible changes, like unicode by default, IE7 was also non backwards compatible so the comparision still holds. (with the exception that IE had a compatibility mode if you sent some magic http headers)
Earlier quoted context omitted.
That would mean someone develops a library that uses features of Python 3, but needs some horrible hacking to port those features to Python 2. Thanks, but no - please make a cut and decide or split it in two separate packages.
> That would mean someone develops a library that uses features of Python 3, but needs some horrible hacking to port those features to Python 2. The "horrible hacking" already exists bundled into libraries and tools like Six and Future. > split it in two seperate packages. That was tried, and failed every time. Because now you end up with two diverging and hard to reconcile code bases. A single-source cross-version l…
Only for the simplest cases. How is Six going to help you write a regex that matches emoji, for example?
On Python 3 you write a range that includes the emoji you want to match, and you're done. On Python 2, that regex may or may not compile, depending on what sys.maxunicode is. If sys.maxunicode is 65535 you have to fall back on a different complicated regex that has a bunch of cases to find emoji in their UTF-16 representation. If you want to avoid that system-specific behavior, you can I guess encode it to UTF-8 bytes and write an extremely complicated regex that finds emoji in UTF-8.
This is my prime example about how something that's easy on Python 3 can require horrible hacking on Python 2. A wrapper library doesn't fix that problem.
Python 2 and 3 have different semantics, and the only way a correct, automated translation between them would be possible would be to emulate one inside the other.
Earlier quoted context omitted.
Armin has backed off of this stance since then. And for good reason. As someone who works with Python text processing extensively, I can tell you that the Python 2.7 text model is broken and dangerous, due to the silent bytes-unicode coercion and misguided use of ascii instead of UTF-8 as the default text encoding. Many people don't realize this and will argue that it's not broken, because they have never fed non-asc…
Yeah, but if you are dealing only with a subset of the English Language in the U.S., and your API endpoint that you are scraping wants to serve to all peoples in all locales in all situations, you are fucked if you want to use Python3 and its csv module. You genuinely are better off using Python 2.7.x and its naive approach to text.
That would mean to me that the API endpoint could be sending me Unicode, in which case Python 3's Unicode-aware CSV is going to work great, and Python 2's csv is fucked. The limitations of Python 2's csv module was one of the key points that moved my company to Python 3.
On Python 3, if you want to be naive about text (not sure why you're celebrating only working in a subset of English, but you have this option), you could open the file as Latin-1 and get the same results as Python 2.
Many CSVs are made with Excel. Excel's only form of Unicode CSV is tab-separated UTF-16. Python 2's csv can't parse those at all, can it?
> And the majority of Python code written does not run under any of the 3.x interpreters. This makes it harder for its users to be productive. What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. For old projects, either you're in a situation where you can spend time porting your code to Python 3, or you don't; but as TFA mentioned pep-404, the writ…
Here we have a person (the author) who has rejected the path that an open source project has taken, and invested the time and energy to move the source along a path they prefer.
In this particular case, there is a natural constituency of people who share that desire but are unable or unwilling to put in the effort to push the source down the path.
When there is critical mass, that group forks off and begins to bring other people along to the alternate path.
At that point the people who endorsed the change in direction come out in force to yell at these people who aren't doing what they are supposed to and threaten them and implore a higher power to emasculate their effort.
Sometimes that works, sometimes it doesn't. But it always results in massive amounts of confusion when someone new comes to the community and sees these two different paths for the same thing and can't really figure out why they are different.
Further because there is no mechanism for "righting" the ship as it were, the diverging paths lead to a lot of wasted time and effort on everyone's part. This happens to be a Python fork but its happened to window systems, video codecs, graphics libraries, data bases, hell even C compilers.
The nice thing about a Cathedral is that the Pope keeps the Cardinals toeing the one and only line.
Reminds me a lot of the Perl 5 / Perl 6 debates.
Earlier quoted context omitted.
Pretty sure they say NOT to rely on the ordered nature of the new dicts. So definitely not something you want to put in your tests.
The intention is to make the order guaranteed in 3.7 or 3.8, AIUI. There was some desire to prove the new implementation before guaranteeing its behaviours (i.e., in the worst case, if it turned out to be broken, they could revert to the 3.5 code and it would be valid).
https://mail.python.org/pipermail/python-dev/2016-September/...
But it is insertion order indeed, not sorting order.
Earlier quoted context omitted.
Yeah, but if you are dealing only with a subset of the English Language in the U.S., and your API endpoint that you are scraping wants to serve to all peoples in all locales in all situations, you are fucked if you want to use Python3 and its csv module. You genuinely are better off using Python 2.7.x and its naive approach to text.
I don't understand what you mean by "your API endpoint that you are scraping wants to serve to all peoples in all locales in all situations". That would mean to me that the API endpoint could be sending me Unicode, in which case Python 3's Unicode-aware CSV is going to work great, and Python 2 's csv is fucked. The limitations of Python 2's csv module was one of the key points that moved my company to Python 3. On Py…
Nope, not without re-encoding to UTF-8 before parsing (learned that out the hard way and found out it's easier to just take excel files as input).
P2's CSV module works byte-based, and basically only handles ASCII-compatible supersets, assuming your special characters (quote chars, field and record separators) are straight ASCII.