20 ms·

This is sad and frustrating. The article is trying to convince people to upgrade to a 7-year-old version of Python! And everyone is still skeptical about it, th

• GFK_of_xmaspast 11y ago
  I don't have any compelling reason to move off of python 2.7, and for my use cases the positives are outweighed by the negatives (in particular getting used to needless changes).
• upofadown 11y ago
  You missed a whole subclass of people. Those that don't like Python3. Personally I believe Python3 took a wrong turn with the approach of converting everything to UTF-32 and making a big deal about the philosophical difference between "strings" and "bytes". I very much suspect the future will be something like how Julia deals with the issue, where UTF-8 can be just left as UTF-8.
  • maxerickson 11y ago
    Recent versions only convert to UTF-32 when a wide character is present (they also use 2 byte characters when that is sufficient): https://docs.python.org/3.3/whatsnew/3.3.html#pep-393-flexible-string-representation https://docs.python.org/3.3/whatsnew/3.3.html#pep-393-flexib... Glancing at Julia, I'm not sure "invalid character index" is really a great thing to have to handle when dealing with text. It does seem that systems for dealing with text will eventually offer various apis beyond just a somewhat disfunctional character api (which I think is a fair description of str in Python 3).
    • upofadown 11y ago
      >Recent versions only convert to UTF-32 when a wide character is present (they also use 2 byte characters when that is sufficient) ... I happen to know this fact. Are you really asking that everyone that comments on a language acknowledge all the possible implementation details? I at no point complained about the memory required to hold strings in CPython so I can't really understand why you would bring this up.
      • maxerickson 11y ago
        Because someone else reading "converting everything to UTF-32" might not be aware of the nuance. That's all.
        • teach 11y ago
          I'm a casual user of Python 2, and I certainly didn't know this, so I appreciated the clarification.
        • upofadown 11y ago
          Sorry for the snark but this has become a trigger for me. Every time anyone disagrees with the way Py3 does Unicode someone will immediately assume that that person is just confused about the implementation.
    • Avernar 11y ago
      > Recent versions only convert to UTF-32 when a wide character is present It's non-BMP characters that trigger the conversion to 4 bytes per codepoint. Unfortunately Emoji are non-BMP and are super common.
      • rspeer 11y ago
        If you're dealing with emoji -- and yes, they are incredibly common -- you'd better not use any Python before 3.3. Non-BMP characters in 2.x-3.2 give you implementation-specific behavior. It can vary from one system to the next. Some string methods fail on "narrow builds" of Python (the ones that store their characters in UCS-2), while others return different results than they would on a "wide build".
  • mangecoeur 11y ago
    Apparently you don't deal with much non-ascii data if you don't like python3's string handling. It's literally the reason I first upgraded, because reading in simple text data on Python2 can break completely. Seeing as literally no language on earth can be written entirely in ascii characters (since even English text can contain words with accents or old fashioned things like the long s ſ) this is a pretty big issue. Yes it is possibly to laboriously add code to check and encode/decode text, that might sometime be text and sometimes binary pretending to be text pretending to be binary. But why go through that pain when you could just use Python3 where things are clear and generally actually work.
    • eeZi 11y ago
      I fully agree. Python 3 makes life much, much easier with non-ASCII languages and prevents the annoying Unicode conversion bugs you see in most Python 2 code bases. It's also very intuitive, which is great for teaching - I've always had a hard time explaining the difference between "strings" and "unicode" objects in Python 2, but the clear boundary makes it straight-forward in Python 3.
      • SeanDav 11y ago
        Not always straight forward in Python 3. Try explaining to your class how to ignore case in string comparisons.
        • zo1 11y ago
          That depends on the type of strings you are comparing. If you include the full Unicode set, you're going to run in to huge troubles in probably all languages simply due to the nature of the Unicode character set, rather than the specific language's handling of strings and Unicode code points. But, personally, if you're teaching Python to a class, whether it's 2.x or 3.x. You should probably stick to using some variation of string.upper() == string.upper() to explain simple comparisons, due to simplicity.
        • squeaky-clean 11y ago
          >Try explaining to your class how to ignore case in string comparisons Okay: You can't. You'll need to convert both strings to the same case, and then compare those. In the majority of cases, you can do: return string_a.lower() == string_b.lower() But sometimes that won't work, because converting case isn't always easy. And that's a unicode issue, not a python issue. It's not even completely a unicode issue, just a "writing can be very weird" issue. For example, "ß" (U+00DF) is a character that doesn't/shouldn't have an uppercase form. Unicode does support it as U+1E9E, but all the examples I know of will convert it to "SS" ([U+0053, U+0053]) instead. Try this in a javascript console, for example. > "ß".toUpperCase().toLowerCase() === "ß".toLowerCase() false > "ß".toUpperCase() === "SS".toUpperCase() true > "ß".toLowerCase() === "SS".toLowerCase() false > "ß".length 1 > "ß".toLowerCase().length 1 > "ß".toUpperCase().length 2 > "ß".toUpperCase().toLowerCase() "ss" Also, try ctrl+f'ing for "ss" on the Wiki page for ß [0] and see what it matches. Or ctrl+f this page for "ß" and it will match every "ss". I think it's pretty neat. [0] https://en.wikipedia.org/wiki/%C3%9F https://en.wikipedia.org/wiki/%C3%9F (edit: You might already know everything in this comment, but I started writing and it ended up being a cool exercise for myself, so I figured I'd submit).
  • Avernar 11y ago
    I agree. Everything is so much simpler when you use UTF-8 everywhere. Being effectively forced to use the ASCII/UCS2/UCS4 unicode type in Python3 is the only thing that has kept me from switching to it.
    • 1st1 11y ago
      The only thing you are forced to think about is whether you're working with strings or with bytes. Unicode is handled transparently (but you do need to know the encoding when you're decoding bytes). How it's stored internally is none of your concern.
      • Avernar 11y ago
        Yes it is. Every conversion to and from the unicode type and every expansion of the unicode type from 1 to 2 to 4 bytes eats up processor time, cache/memory bandwidth and puts more pressure on the garbage collector. And I don't want to be forced to distinguish between strings and bytes. To me they are one and the same as I use UTF-8 for everything. Not once in my code do I need to encode/decode anything.
        • mark-r 11y ago
          Most of us aren't so lucky. I really do wish we lived in a 100% UTF-8 world. But even if we did, I don't see how e.g. regular expressions would work.
          • Avernar 11y ago
            The world seems to be headed to UTF-8 for everything. That's why having Python3 force us away from it doesn't make sense to me. As for regular expressions, they work perfectly if your delimiters are in the ASCII range. If you're trying to match a single character then they don't work for Unicode even when using Python3's unicode type. The reason is that code points are not characters.
            • 11y ago
• shubhamjain 11y ago
  I don't believe its the same. Code from old version of PHP could still be expected to run the same in the newer version except for "deprecation" warnings maybe. Probably, a reason why it is not easy for PHP devs to fix all typecasting quirks their language has. Python 3, on other hand, has tried to fix many design decisions and hence requires some transition effort. The effort is many folds more with so much software already written in Python 2 and large codebases. I am not surprised the adoption is slow.
  • frik 11y ago
    There were plans for a never released PHP6. Even some books were published for PHP6, it was meant to be the big unicode release. Most of its feature made it to the 5.4 version. In the end, it seems that it was the better decision to introduce new features in a smoother way. PHP hasn't suffered the problems that exists with Python 2 to 3. Although, there was the PHP4 to 5 transition that broke the older object oriented implemention - though most never used OO in PHP4 as it was known to be slow - so it wasn't a problem for the community.
    • PaulHoule 11y ago
      Note also that Sun/Oracle has periodically come out with updates for Java and these get taken up quickly, even by "enterprise" sorts of people. The enthusiasm for Java 8 is huge and the transition from 7 -> 8 is astonishingly trouble free and the 6 -> 7 transition was relatively bad because of the way in which JAXB creates POJOs changed in a way that broke people's assumptions. Java has done a great job of evolving over time -- they made the controversial choice of using type erasure in generics. This makes generics much less useful than they are in C#, but Java kept compatibility between the classic and generic collections and C# didn't. Thus the C# code base has two different syntaxes for collections, particularly in the stuff that comes from Microsoft.
      • __jal 11y ago
        The cynical lesson I've taken from watching languages evolve over time is that, if you wish to provoke mass-migration to your new language version, having either a missing feature people want, or an annoying misfeature people don't, is really important. Java and PHP have had both in spades. Back in the Perl 4 days, people really wanted a real object system[1]. Python 2 (aside from a few things that annoy the crap out of me, but apparently not many others) is a pretty complete, fairly decent language. Perl5 is pretty complete and people are pretty happy with it. (Well, the ones who write in it.) [1] Yes, I know, not here to argue the semantics. It is "sufficiently OO" for what people want to do with it.
• strictnein 11y ago
  Speaking of Node, it still requires Python 2.7, right? Or at least node-gyp does: https://github.com/nodejs/node-gyp https://github.com/nodejs/node-gyp
  • gsnedders 11y ago
    gyp itself still relies on Python 2 (and, to my knowledge, Google has mostly moved on gyp, so they're unlikely to do anything large to it).
• eeZi 11y ago
  Python 2 devs are also missing out on the amazing ecosystem developing around the new async features. There are asyncio ports of many popular and less popular libraries, and it even has a nicer syntax than NodeJS.
• msellout 11y ago
  I think we're going to see the switch occur quickly now. This year I've seen several large enterprise projects using Python 3. Also, the release of v3.5 brings useful features that will not be backported as 2.8.
  • deleted 11y ago
    [deleted]
• njharman 11y ago
  I think there is way less "anti" python 3 attitude than there appears. A few haters, a few blog spam/click baiters, a few people who never even looked at python3. Vast majority of people using Python3 (me included), just use it. It's not a big deal. No reason to toot my horn over it. There is lots of FUD from early 3.0-3 days. Python 3.5 is solid and well supported by 3rd party libs check this out https://caniusepython3.com/ https://caniusepython3.com/ Python3 has been adopted, now. It just isn't newsworthy so we don't hear about it.
  • vegabook 11y ago
    This is true and incomplete at the same time. It's true that 3 is happily happening for many people, effectively and without fuss. But it's incomplete to pretend the schism is not an issue; not to try to understand the pro-2.x points which many reasonable users have. Its a huge issue, even now, and to pretend it's not there is to do BOTH pythons a disservice because it will simply serve to feed the disagreement, to the detriment of both flavours of the language. The Python 3 project needs to understand where it went wrong, acknowledge it, 'better language' arguments (true-ish but largely ineffective) notwithstanding, and try to bridge the community. Yes the 3 segment reasonably wishes all this would just go away so we can all focus on moving python forward, but it's not going away. It must be adressed without yet another post about 3 being better, which simply makes 2.7 people feel like second class citizens. They've heard all the arguments before.
    • mixmastamyk 11y ago
      > The Python 3 project needs to understand where it went wrong, acknowledge it... Already happened years ago. Breaking backward-compat is the issue, and is a difficult situation for any popular platform. Guido has mention it won't happen again.
  • Animats 11y ago
    No, it hasn't, based on download stats of packages. Guido found this out the hard way when he went to work for Dropbox. They run mostly Python 2.7 code, and now he has to maintain it. Also, PyPy is 2.7 compatible, although there's a 3.x beta.
• incepted 11y ago
  It's unproven because nobody uses it and nobody uses it because it's unproven.
• rdtsc 11y ago
  > And everyone is still skeptical about it, They are not skeptical. Nobody thinks "yeah if I just wait long enough, Python 3 will go away and 2.8 will come out". They just don't see an incentive to update. Simple as that. It is basic economics of time and money. Python 2 wasn't terrible and Python 3 isn't dramatically better. Unicode and other stuff in Python 3 is nice. Is it nice enough to start digging into stable, working, money making code just to say "Yay, Python 3"? I think the development community has spoken by how it was handled. It's gonna happen but it will happen at a very slow pace. Imagine this alternative scenario -- "Python 3 brings 3x speed improvement + removed GIL". Ok, I bet you, there would have been a much faster adoption because now there is a greater incentive to justify it. People would think "Yeah, I'll destabilize my code a bit but I gain performance, I can do that". Someone in a sibling comment suggested "They should have just stopped updating security patches for 2.7, that would have forced them to use 3.0". That's ok if Python holds a monopoly on development languages. But it doesn't. As soon as that happens developers will not just look at updating to Python 3, they'll start looking at other ecosystems: Go, Elixir, Java, Clojure, Scala, NodeJS etc.
  • mangeletti 11y ago
    I could not agree more. To add to this; if it included even a 2x speed up / memory reduction, I think 90% of everyone would have switched by now, and you know what else? Go probably wouldn't exist.
    • thrownaway2424 11y ago
      This is a good point. Go is a direct response to Google's experience with Python.
  • s73v3r 11y ago
    I would say that actual, continued support is an incentive to update.
  • jrumbut 11y ago
    I think the energy spent supporting Python 2 and the inability to really unify and focus the community on Python 3 is preventing or delaying that kind of dramatic improvement. If people would rather move to another ecosystem rather than update their code that's fine. The Python community doesn't get paid a nickel every time the interpreter runs, (at least slightly) engaged users are what move Python forward.