22 ms·

Why I'm Making Python 2.8

• gigatexal 10y ago
  Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. Python 3 I think people and businesses with python 2 code would be better off moving their code bases to python 3 instead of doing things like this.
  • wfunction 10y ago
    > Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. I hate Python 3's removal of the (lambda (key, value): blah) tuple unpacking syntax, and the forcing of parentheses for print statements. They might seem minor but they aren't for me. So I'm not at all eager to move to version 3 and don't really see any benefit. Not sure if those who aren't migrating feel the same way, but I wouldn't be surprised if some of them do. (Edit to address comment below: There are more issues I have with Python 3. It allows more bugs to slip through, for instance. I actually particularly like a comment I just wrote, so I'll link to it here: https://news.ycombinator.com/item?id=13145299 https://news.ycombinator.com/item?id=13145299 Do note that this was added after the reply below.)
    • BozeWolf 10y ago
      Benefits? Unicode. Async. Extended library. Required keywords. syntax inprovements (lots of m, many more than just the removal of the print statement). Type hinting.
      • wfunction 10y ago
        > Benefits? I meant I don't see any benefits for me, not benefits for other people. I assumed that was clear; sorry if it wasn't. > Unicode. Yeah, but some people have still been living without the changes, and it's hardly enough of a reason on its own (for me anyway) when there's other things I hate about the language. > Async. It's a nice feature, yeah. I can live without it, as people have for many years. Maybe if I was used to having it around I wouldn't want to go back, but I'm not. > Extended library. Cool! I'm not sure what exactly falls under this that I'm supposed to be missing, but pip install has sure been taking care of everything in the blink of an eye in version 2. > Required keywords. Cool! I need it about as much as I need a donut. > syntax inprovements (lots of m, many more than just the removal of the print statement). nonlocal is literally the only positive one I can think of right now that I'd actually care about. But then again, it comes up maybe 50x less often than the parentheses I have to write for print, or the tuple unpacking that I have to do. So yeah, it's hardly a reason to migrate. > Type hinting. Nice to have. I'm living just fine without it. Maybe I'd have migrated if it actually optimized things or did something more useful.
        • BozeWolf 10y ago
          Well, things change, especially in tech. For better or worse, but most of the time for the better. You should read some changelogs of past python 3 releases. 3.6, for example, has ordered dicts by default. Which is quite convenient when you need to write test testing a small dict with two items for example. I like driving an old muscle car, most of m look beautiful and bring me everywhere i want. But damn, those new cars changed a lot and are much more comfortable. (But they do break as much ;))
          • nicpottier 10y ago
            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.
            • gsnedders 10y ago
              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).
              • BozeWolf 10y ago
                No it is in 3.6 already! It used to be not guaranteed. https://mail.python.org/pipermail/python-dev/2016-September/146327.html https://mail.python.org/pipermail/python-dev/2016-September/... But it is insertion order indeed, not sorting order.
                • gsnedders 10y ago
                  The behaviour is there in CPython, yes. But the language documentation doesn't, deliberately.
      • meddlepal 10y ago
        People often bring up the unicode thing but tons of Python code is backend glue code that really doesn't care at all about unicode.
    • xrisk 10y ago
      So you _hate_ Python 3 because of two changes in syntactic sugar? I would understand if you hated it because of the real breaking changes, but no... I think you just don't comprehend the multitude of problems that Python 3 fixes by handling strings correctly... Maybe you've never handled Unicode before.
      • wfunction 10y ago
        > So you _hate_ Python 3 because of two changes in syntactic sugar? First of all, the tuple unpacking one is a HUGE readability AND maintainability issue; it's not just syntactic sugar. var[0][1][2] is not only far less readable than the unpacking notation, it doesn't even have the same semantics (doesn't enforce the structure of the tuple). That means Python 2.7 helped me catch more bugs. Think about that! Second, no, I just listed the two that irritated me the most every time I tried to switch, because they were the first things that came up by far the earliest and most frequently. Small inconveniences can be amplified through their frequencies. There are lots of things I don't like about it though... division becoming floating point division, having to say list(foo.items()) or list(map(...)) instead of just foo.items(), etc... again, more verbosity and typing for common cases where I really didn't mind the old way. If I wanted imap(), I could've just used imap; they could've just moved that to __builtin__ and made my life easier that way. By the way -- the lazy nature of map(), etc. also means you catch fewer bugs now. Again, think about that! Just because it looks more efficient, that doesn't mean it's actually better. If there's anything I've learned, it's that even the smallest things tend to come with non-obvious tradeoffs. Finally, regarding strings: if you look at my earlier comments, yes, I already acknowledged the Unicode changes were for the better. Awesome. I agree. Cool? OK, but there are other things in the language besides Unicode though, and they're not as awesome. I don't spend my entire programming life dealing with Unicode strings, so I care about other things too, and they make my life harder. Simple as that.
        • js8 10y ago
          Regarding tuple unpacking, instead of writing, say: def foo((birthname,surname)): ... you can write in Python 3: def foo(name): birthname, surname = name ... It's not less readable. I also missed it in the beginning, but it's not really a big deal. (I think they couldn't keep the feature because of how '*' is used, but I am not sure.) Edit: If you have problem with this in lambda expression, just create a named inner function. It's a feature/shortcoming (depends on POV) of Python that you cannot bind variables in an expression. I hope you understand that they couldn't keep the feature in lambdas if they didn't keep it in proper functions. I am sure if you think about other things, there are good reasons to do it the way Python 3 does it, usually there is a hidden case where things need to be disambiguated (like your list() examples).
    • gigatexal 10y ago
      That seems kinda petty. Surely you can work around that. If they really were killer features that many devs used I doubt they'd have been deprecated and removed in python 3. I do agree that though I wish lambdas could be more useful instead of one liners.
    • kstrauser 10y ago
      > and the forcing of parentheses for print statements You mean print functions. I love the new change because you can pass "print" around like any other function now, letting you write code like: def my_map(data, func): for item in data: func(item) my_map(dataset, insert_into_database) # For testing my_map(dataset, print)
  • jzwinck 10y ago
    Companies with Python code are probably better off keeping their working, tested code than switching to an incompatible interpreter and set of libraries which among other things will print "b'Hello',b'World'" into their mission critical CSV files. Yes, the built in csv module really does that in Python 3.
    • aidos 10y ago
      But people that have that csv issue have deeper lurker encoding issues they're probably not aware of. Sure, don't change the stuff that works and cause yourself unnecessary pain, but don't blame python 3 for your misencoded data.
      • jzwinck 10y ago
        Oh we are perfectly well aware of our encoding issues. In NumPy, one of the most important libraries in Python 2 or 3, strings always take one byte per character. And it's not going to change. So the built in csv module needs to support a reasonable behavior. Which it does not. If a company tries Python 3 and discovers basic things like CSV produce utter gibberish, they would do well to opt out. And they do--in droves. My data is not misencoded, you see. It's just misunderstood.
        • guitarbill 10y ago
          > So the built in csv module needs to support a reasonable behavior. Which it does not. It could be argued that the csv module's behaviour is reasonable, and NumPy's isn't. (I'm not 100% sure about all the details of this issue) Hopefully, NumPy will change it's behaviour to match Python 3, but if not you could still use the NumPy CSV routines like `loadtxt` or `genfromtxt` [0]. So then this becomes a documentation change to add some warnings to both modules. > they would do well to opt out. And they do--in droves. This is simply not true. They would do well to handle strings properly and so avoid bugs in future - something Python 3 actively encourages, and Python 2 obscures. And while I can't speak for every company, our metrics show that our Python 3 code has far less customer issues than Python 2, Perl, or Ruby. Now that's business value. (Edit: I mean it's hard to make the comparison - the Perl code is e.g. older - but we're writing code now, and when the interns add new stuff to the Python 3 codebase, it breaks less. All of them are still actively developed, and the Ruby one is about as old as the Python 3 one). [0] https://docs.scipy.org/doc/numpy/reference/generated/numpy.loadtxt.html https://docs.scipy.org/doc/numpy/reference/generated/numpy.l...
  • supergreg 10y ago
    What about not spending time and money and just keep using python 2 for software that already uses it. And only use python 3 for new code bases.
    • beojan 10y ago
      This is how you end up still running fixed-format Fortran code in 2016. If your software is being actively maintained, it's time to move to Python 3.
      • bmh100 10y ago
        And the differences between F77 and Fortran 2008 are monumental. It's like they're 2 different languages.
      • username223 10y ago
        This is how you keep using those efficient, numerically-stable subroutines written by a smart guy who retired 20 years ago in your new code. Unlike Python, Fortran has managed to add significant new features without breaking old code.
        • guitarbill 10y ago
          Unlike Python, Fortran hasn't seen an increase in usage and hasn't brought the joy(?) of programming to thousands of new programmers in the last 10 years. So sticking to Fortran or backwards compatibility blindly doesn't solve all the problems, either. Maintenance is key. Most people don't stick around for 20 years anymore either. I know I'm going to have an easier time finding a new hire for a Python codebase. And he's going to have a far better chance at understanding said codebase. Code which nobody knows how to maintain will hurt us either with a fiendish bug, or limit out growth. So for me, slowly moving away from legacy stuff is good business value in the long run. Remember, you can never be sure that Fortran code is 100% bug free. The test of time is as good as any other test, but not perfect.
          • 10y ago
  • gigatexal 10y ago
    I should add that in my mind this is akin to working around a design flaw instead of refactoring and modernizing and upgrading. The python deva have provided numerous tools one of which is the 2to3 tool for simple things.
  • meddlepal 10y ago
    Python programmers and companies with python code should the time and effort delivering new features for their customers instead of spending that time and effort forward porting stuff to python 3 because python 3 isn't delivering enough additional value to justify switching. I think people and businesses with python 2 code would be better off continuing to improve their code bases with new features instead of doing things like this.
• js8 10y ago
  IMHO, Jython 3 would be more useful than Python 2.8, but it's your project. We have a project at work and the only reason we need to support 2.7 is because we want to run under Jython. Anyway, I would like to hear other people's use cases for Python 2.7.
  • kensai 10y ago
    Isn't Jython (generally) dead? The main site seems to be stuck in 2015.
    • js8 10y ago
      AFAIK Jython supports Python 2.7.. so it seems dead because Python 2.7 is dead. (I am not a big fan of Jython myself, being a big fan of Python 3.)
    • aargh_aargh 10y ago
      It's not dead, it's just really slow. The 2.7 release has been very long in the making, released only 18 months ago. There are stabilization releases to it still coming out. There's a tiny, but dedicated group building it and it shows. Jython 3 is possible if you're willing to put your money where your mouth is.
      • gsnedders 10y ago
        There's been an imminent 2.7.1 release for a while now, so that will likely eventually ship. AIUI, some of those who were paid to work on it previously are now doing so only in their spare time.
        • jimbaker 10y ago
          Yes, that would be true on all counts :) as one of those Jython maintainers. Jython 2.7.1 is currently bottlenecked on finalizing support on Windows for pip/setuptools. It should be the last fix.
  • smcl 10y ago
• grx 10y ago
  I don't think this is a good idea simply because it reduces the need to upgrade your library from 2.x to 3. It's a clear cut and a good chance to weed out unmaintained libraries
  • kevincox 10y ago
    Or possibly it makes it easier to have code that works on both. Although that requires this to catch on enough that 2.7 compatibility isn't required.
    • grx 10y ago
      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.
      • sandGorgon 10y ago
        isnt that what six already does ? https://pypi.python.org/pypi/six https://pypi.python.org/pypi/six
        • masklinn 10y ago
          Future supersedes Six: http://python-future.org http://python-future.org
          • jsmeaton 10y ago
            Literally the first time I've heard of python-future. How is it that you claim it supercedes six?
            • masklinn 10y ago
              > Literally the first time I've heard of python-future. So? > How is it that you claim it supercedes six? Its `future` library goes further than Six and it provides CLI tools to convert both Python 2 and Python 3 code to 2/3 code.
• sandGorgon 10y ago
  this is incredible - give me unicode support in python 2. asyncio ? probably .. i'll still be happy with gevent. This is a clear path for a python upgrade.
  • orf 10y ago
    Python 2 supports unicode and asyncio.
    • sandGorgon 10y ago
      i know it does - but it would be nice to have the everything-is-unicode mechanism of python 3. Asian developers hit unicode problems before US based developers because of the natural differences in underlying OS language.
      • lloeki 10y ago
        But then it wouldn't be compatible with Python 2 code, so you might as well use Python 3
        • sandGorgon 10y ago
          http://python-future.org/unicode_literals.html http://python-future.org/unicode_literals.html nope - you can mix them in python 2 code. The way it should have been done in the first place.
      • orf 10y ago
        ... You can't have your cake and eat it. If you want Unicode everywhere then you use Python 3, because it's a breaking change. Saying you'd want it in Python 2 is a confused way of saying "I need to use Python 3".
  • masklinn 10y ago
    > give me unicode support in python 2 Nope. Can't be done without getting Python 3 either way, because Python 3's text model is not compatible with Python 2's. That is why the core team allowed the other breaking changes, because software was going to be broken in the first place.
• smegel 10y ago
  This isn't bound to confuse anyone.
  • singularity2001 10y ago
    This comment wasn't ironic
• deleted 10y ago
  [deleted]
• toggafgnadx 10y ago
  The worst thing about open source is that people can do stupid stuff with your software. If you're going to create this abomination, at least do us all a favour and DON'T call it Python. Call it Retardython or something. I don't want to imagine people coming into the official support channels and claiming they are using "Python 2.8", then other people lecturing them about what that software really is, etc. Sounds like a horrible waste of time. (Source: I spend many hours a week helping fellow Python users.)
  • izym 10y ago
    Very good points, but you should try to keep a more civil tone.
    • snvzz 10y ago
      We can do without the tone policing.
  • harryf 10y ago
    Python is trademarked by the Python Software foundation. IANAL but pretty sure that means he doesn't get to call it Python 2.8
    • ufo 10y ago
      Only if the PSF does something about it...
      • bb611 10y ago
        If they don't protect their trademark they open themselves up to what is essentially loss of the trademark in the US. They could license it to Python 2.8 for free if they want to, though it seems unlikely.
  • singularity2001 10y ago
    "DON'T call it Python" They shouldn't have called it 'Python' 3 in the first place when it's practically backwards incompatible
• mathgenius 10y ago
  Christian Tismer tried this a couple of years ago [1]. I guess the intention was a bit different: he wanted to have stackless features in python. It's not clear to me the reason he decided to back down, whether because of licensing issues or just because the other python developers didn't like it. [1] http://www.stackless.com/pipermail/stackless/2014-January/006043.html http://www.stackless.com/pipermail/stackless/2014-January/00...
• yoz-y 10y ago
  I make software that people can write plugins for in Python. After months, years of struggle we finally dropped support for Python 2 because our small team could not bear the overhead of maintaining two bindings. We work a lot with researchers in signal processing domain and we have hard time as it is to get people to use Python 3. Please, do not put obsolete software on life support.
  • wfunction 10y ago
    > Please, do not put obsolete software on life support. Downvoting because Python 2 is anything but obsolete. People still love using it.
    • js8 10y ago
      I am glad that you explain why you downvote, but I disagree. The fact that people love and use something doesn't mean it cannot be obsolete. At work, I care about more than 35 years old software. It is obsolete (it's written in mainframe SAS with 3270 green screens and some assembly), but people still love using it, mainly because there is no good alternative and it does the job very well.
      • wfunction 10y ago
        What makes something obsolete in your eyes then? Just because some people want A to replace B, that makes B obsolete? For reference, Oxford dictionaries define (..."define"? are multiple dictionaries involved here?) "obsolete" as: 1. no longer produced or used; out of date. Clearly Python 2.7 is in widespread use, and version 2.7.12 came out just a few months ago, so it's neither "no longer produced" nor "no longer used" nor "out of date"...
        • js8 10y ago
          Python 2.7 is outdated by Python 3.5. The fact that there is a bugfix release doesn't change that. I mean look at other things. You can still program in C 89 or FORTRAN 77 or COBOL 74 (and no doubt there is somebody still supporting compilers and runtimes for those), but they are all obsolete standards. Addendum: I think for standards like programming language semantics (which in case of Python is directly embodied in the C implementation), "obsolete" means there is a new standard by some official body (say, the developer of the old standard) that addresses shortcomings of the old standard. So "out of date" is the fitting equivalent of "obsolete" from the Oxford definition.
• nzjrs 10y ago
  I can't fault a single thing in his justification. This should have been the approach to modernising python all along.
  • masklinn 10y ago
    > This should have been the approach to modernising python all along. The core driver for the Python 3 break was the fix in text model, this is what allowed literally everything else as it completely broke existing code. And I, for one, think it's one of the most important improvements of Python 3, the text model of Python 2 is a giant mess and makes it very hard to correctly deal with non-ascii text for any non-trivial software, especially in large teams where not everybody will carefully evaluate the text-ness of their code..
    • sirclueless 10y ago
      > the text model of Python 2 is a giant mess and makes it very hard to correctly deal with non-ascii text for any non-trivial software There are counter-arguments to this. Armin Ronacher, author of (among other software) the excellent Flask web framework, thinks that Python 2's system of codecs and byte streams is better in practice [1][2]. Reasons include: You can do byte -> byte conversions with codecs that are no longer possible. You can better handle text encodings besides UTF-8 (and here he describes several embarassing failures of Python 3 to handle OS paths correctly). You can write single APIs that handle byte streams like gzip and text encodings like UTF-8. [1]: http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/ http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/ [2]: http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/ http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/
      • dom0 10y ago
        I don't think it's honest to post this without context, and without mentioning that in the five years that passed most of these things were remedied, and indeed, some things were already remedied at the time of his writing. Some points Armin makes are valid and remain valid for Linux-ish systems, but have been shown and refuted countless times for other operating systems; Python is not a Linux-only show. I won't re-iterate all that here.
• lloeki 10y ago
  > 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 writing has been officially on the wall ever since 2011 so at that point you have to admit you did choose to incur tech debt and do nothing about it, so the claimed loss of productivity is on you. > Unlike 2.7 code, Python 2.8 wouldn't be able to guarantee exact 3.x compatibility, since there are some python scripts that will run under both Python 2.7 and Python 3.x but produce different output, and Python 2.8 chooses the 2.7 behavior in these cases. What a terrible, terrible situation. Now you'll have "python" code that will neither run on 2.7 nor run compliantly on 3.x. As for the latter, please explain how that will alleviate anything on the following point, since behaviour at runtime will be subtly different: > adding these remaining Python 3 features would greatly simplify running code targeting Python 3, and allow people to use Python 2.8 to run a mix of Python 2 and 3 code. I don't know what recourse the PSF has but maybe they should even go all in and defend the "Python" name so as to prevent confusion and stop a potential community fracture. Just call it anything else but "Python 2.8" is not Python.
  • staticassertion 10y ago
    > What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. Except when they aren't. And then what? I've run into this multiple times. Sometimes there's a branch of the project for 3 that's underway, and I sit and wait. Other times it means dropping the project or committing to reimplementing a library.
  • epberry 10y ago
    Yes totally agree. In the end this won't matter because the momentum of the ecosystem is so great at this point but it just baffles the mind that someone would think this is a good idea, especially with the "can't run on 2.7 or 3.x" situation.
  • ceronman 10y ago
• thesquib 10y ago
  What about contributing towards a project which enables python2 code to run in python2? Seems like this would help the move to python3 overall... Something like this? http://python-future.org/translation.html http://python-future.org/translation.html
  • masklinn 10y ago
    > What about contributing towards a project which enables python2 code to run in python2? Surely that already exists?
• lordkrandel 10y ago
  Hope you don t succeed
• dom0 10y ago
  > I've been working on Python 2.8 (not an official Python release) It is very dishonest to call it Python 2.8 then.
  • labrador 10y ago
    I suggest Monty 2.8
• mathgenius 10y ago
  People don't seem to be considering the possibility that a stagnant python 2.7 may actually be a reason to like that version of the language. I must admit it is nice to not have those oh-so-keen python developers messing with my favorite language. However, I recently had a gig working in py3. Apart from screwing up every single print statement for a long time, it was entirely drama-free, and actually pretty great. There really is a difference between living and dead languages I think. 2.7 is the latin of python.
  • ant6n 10y ago
    why can't print be both a function and a statement...
    • kevin_thibedeau 10y ago
      The print statement has a lot of special magic like '>>' and trailing commas that uglifies the parser.
      • ant6n 10y ago
        I don't get this. There's a tiny fraction of Python users who care about the complexity of the language parser. But many hate the print-tax.
  • int_19h 10y ago
    Oh, people are considering that possibility very much. But the notion of Python 2.8, with new features backported from 3.x, is kinda the opposite of that approach, and is very much "developers messing with my favorite language".
• xrisk 10y ago
  Now you're just adding on more technical debt for users of Python 2. Who's going to maintain your Python 2.8? What happens when there are conflicts between your Python 2.8 and Python 2.7? This is just a really bad idea IMO.
• mattbillenstein 10y ago
  This is gonna be great. https://vazor.com/drop/gif/bill_hader_popcorn.gif https://vazor.com/drop/gif/bill_hader_popcorn.gif
  • mattbillenstein 10y ago
    I meant -- entertaining great -- people see Python2 vs Python3 as a holy war, it's just software guys.
• silent1mezzo 10y ago
  What another load of crap. Call it something else but this isn't Python. I'd never use this because it's not official. Who knows if or how long it'd be supported for or if any backdoors would/could be introduced. I've scheduled time this year for my teams project to update to Python 3. It's expensive in the short term but in the long term we get continued support and new features which is a huge win.
  • nilved 10y ago
    Do you trust PyPy? It's not official either.
• snippet22 10y ago
  You need one of these. https://golang.org/cmd/fix/ https://golang.org/cmd/fix/
• supergreg 10y ago
  Just call it Unofficial Python 2.8 instead of Python 2.8
• yladiz 10y ago
  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 understanding is that with the planned phase out of Python 2 and Python 2 only receiving bug fixes at this point, much of the industry is transitioning to Python 3 (either currently doing so or planning to) and so it seems relatively fruitless to attempt to build upon Python 2. I personally think the effort put into this would be much better spent making tooling around Python 2 to 3 transformations. I also think it's pretty irresponsible of the author to call this Python 2.8, because it may cause confusion to developers unfamiliar with the history and come from a tutorial that is still in Python 2 (it does show up on the first page of Google for me). It's also especially irresponsible and hubristic to attempt to make a language that is seemingly compatible with both Python 2 and 3, because 1) I trust that if it was possible Guido and the other developers would have made it, and 2) it can cause significant confusion when code doesn't work when it hits an edge case, and then the whole tooling around it can't be guaranteed to work. The last thing I'd want in my programming language is unaccounted for ambiguity.
  • dismantlethesun 10y ago
    I don't know about that. It forked a Python compiler, and is fully interoperable with 100% of Python 2 code, and much of Python 3 code. It's even compatible with Python C extensions. 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.
• holografix 10y ago
  Cuz you have too much free time?
• andy_ppp 10y ago
  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. The reason this happend (and is still happening) are human not technical.
  • jnbiche 10y ago
    > 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 looking at the evidence. For example, when you go to download Python at the python.org website, you're still presented with a choice between Python 2 and Python 3 side-by-side, looking for all purposes like equivalent choices (Python 2 should be much less prominent and toward the bottom and/or the download button should be much smaller than the Python 3 download button)[0]. And then, when you follow the link for "Wondering which version to use?", you get a full page worth of hemming and hawing, and cost-benefit analyses and so on[1]. In fact, they should be saying something like: Always use Python 3 unless you have a strong reason to do otherwise. This typically only applies to people who have large legacy code bases and are for some reason unable to upgrade, or else need a special legacy library only available in Python 2 (most libraries are available in Python 3)." So wow, having read the official python.org statements on the Python 2 vs 3 issue, I'm pretty appalled. No wonder some people who are relatively new to Python are confused or surprised. I'm on Debian or Ubuntu mostly and so download Python via package manager or PPA, or build from source. So I had no idea. It's also been a huge mistake for GVR to have allowed so many new and attractive features to be backported to Python 2.7. It's taken away a significant amount of incentive for people to make the move. Python 2.* should have been bugfixes only for a long, long time now. That said, if you're in charge of significant amount of Python code for a company and you've not seen for years that Python 2 is a deadend, you've either been engaging in wishful thinking or oblivious to what's happening in the Python community. 0. https://python.org/downloads/ https://python.org/downloads/ 1. https://wiki.python.org/moin/Python2orPython3 https://wiki.python.org/moin/Python2orPython3
• andy_ppp 10y ago
  Obligatory: https://xkcd.com/927/ https://xkcd.com/927/ Edit: I don't understand the downvoting here; adding Python 2.8 to Python 2.7 and Python 3 is the proliferation of new standards which is what the XKCD is talking about.
  • MawNicker 10y ago
    Are the other standards inclusive or repressive?
    • orf 10y ago
      Are you implying Python3 is repressive?
      • deleted 10y ago
        [deleted]
      • deleted 10y ago
        [deleted]
      • pooper 10y ago
        > Are you implying Python3 is repressive? I am not GP but I think the xkcd is relevant. OP is delusional if they think "Python" 2.8 is even python. It is not. From what I've read so far, it is a fork of Python 2.7. There is nothing wrong with that. What is wrong is calling it Python.
      • coldtea 10y ago
        "Port your old code or be left behind when we cut off 2.x line" is.
        • orf 10y ago
          Please please please explain how that is inhibiting or restraining personal freedom. Or how it is inhibiting or preventing the expression or awareness of your thoughts or desires.
• babo 10y ago
  As a Python 2.7 project why would I trust more to this unofficial version with a lot of backported code compared to the tried and tested 2.7 to 3 route? What would happen with my python 2.8 when it needs to be converted to the official python 3?
• cesarb 10y ago
  Reading a thread from the last time something like that was proposed (although the only change in that proposal was that 2.8 would, on Windows, use the C runtime from a more recent MSVC compiler), I found a relevant argument (https://mail.python.org/pipermail/python-dev/2013-November/130485.html https://mail.python.org/pipermail/python-dev/2013-November/1...) against this "Python 2.8" idea: What if more than one person did that? (paraphrasing Raymond Chen's "What if two programs did this?") There can be only one official Python 2.8, but since it will never exist (see PEP 404), there can be many unofficial mutually incompatible "Python" 2.8 implementations. Therefore, calling it "Python 2.8" is a bad idea.
• thewhitetulip 10y ago
  I never knew that despite Python 3 is called the future by PSF and has been around for a ling time, people still want to stick to Python 2. I mean it isn't the 2013 that libs aren't ported, most famous ones generally are ported. Don't know what the problem is.
  • bb611 10y ago
    Legacy python 2 code & an unwillingness to refactor it for python 3.
    • thewhitetulip 10y ago
      I can understand a project with millions of lines of python2 code, it would be a headache to port it all to python3
  • jchassoul 10y ago
    Unwillingness to refactor and people bad habits, mostly bad habits like print 'this stuff out'... simple bad habits humans we have that a lot.
• grillwork 10y ago
  the python community is like a snake eating its own tail
• eej71 10y ago
  It's too bad the python 3.x fans can't see this as feedback about how difficult it for users of 2.x to upgrade to the latest and greatest. Many 2.x folks have sprawling code bases and complex operational needs. The 3.x advocates seems to consistently ignore that. Shoot the 2.8 messenger all you want for choosing to call it Python 2.8, but don't dismiss the issue that drives thoughtful people to get value out of this strategy.
  • fatbird 10y ago
    The python maintainers and the 3.x fans do see this, and know this, and decided to do it. They knew there would be a cost in community, and decided it was worth it. They haven't been oblivious, and they've made several large concessions in 3.4 and 3.5 to increase the ease of migrating. Stop denigrating them.
• luckydata 10y ago
  The existence of this project shows a tremendous lack of judgment on behalf of the creator and does exactly zero good things for the python community.
• Zane55 10y ago
  > I've been working on Python 2.8 (not an official Python release) because I want to give all the people who use Python 2 access to the Python 3 language features, which I think are actually pretty cool. Theres a module called __future__ for exactly this purpose
• dekhn 10y ago
  Thanks for doing this! I took a look at the arguments underlying the proposed switch to Python 3 and came to the conclusion that they did not meet the necessary threshold of effort to switch. Instead, I want to see every feature in Python 3 backported into 27. I don't think the unicode change can be accomodated, but 99% of the rest of the new features in 3 can.
• hartator 10y ago
  We should make this Python 4.0 and move on. Some high paid google engineers working the "official" 3.x will be pissed, but that's life. I am sad to see the schism in Python community.
  • rch 10y ago
    A non-trivial number of people seem to want this, but why does it need to be called Python? Keep the syntax and C extension compatibility, but ditch the name. One could even work out a means of selectively bringing in ideas from elsewhere: - Concurrency from Erlang (http://queue.acm.org/detail.cfm?id=1454463 http://queue.acm.org/detail.cfm?id=1454463) - String handling from Go (https://blog.golang.org/strings https://blog.golang.org/strings) - Lightweight data classes (https://kotlinlang.org/docs/reference/data-classes.html https://kotlinlang.org/docs/reference/data-classes.html) - Syntactic macros from Nim (https://hookrace.net/blog/introduction-to-metaprogramming-in-nim/ https://hookrace.net/blog/introduction-to-metaprogramming-in...) - more from Lua, Julia, Scala, and Haskell (within reason) There are already plenty of examples of Python modules that implement significant modifications (e.g. Cython, Rpy2, Dask), so I don't think it would really feel all that different from typical Python programming.
• rch 10y ago
  > there are some python scripts that will run under both Python 2.7 and Python 3.x but produce different output OK, so it may well be terrific, but it should really have a different name.
• ianamartin 10y ago
  Just a couple of things I want to point out here. 1. Calling it Python 2.8 is a really bad idea. If you want to fork Python in this way, great. I'm sure very few people in the community would have a problem with it if you called it Brothon or P8thon or Hackthon (could run into trouble with that one, but who knows?) or IHate3.xThon. You can call it LifeOfBrython or Snake, depending on how much you care about where the name came from. Guido van Rossum is one of the least litigious people you can find in the open source community. When he wanted people to stop naming packages after PEPs (pep8, pep257), he didn't try to go to court and figure it out later. He talked to the maintainers of the packages and explained why he thought it was problematic [0]. I wouldn't expect a cease and desist showing up anytime soon, but it's in poor taste, and I hope you reconsider it. Python is not yours just because you are free to use it and do as you please with it. It's really stretching the concept of open source for you to unilaterally declare a collection of hacks to be a point release that's been specifically addressed and decided against by the community as a whole. 2. I have so much sympathy for people who must maintain Python 2.x applications and cannot make the business case for putting the time into porting it to Python 3. I'm in that situation myself right now, and I have been for years. I can't find a compelling argument to warrant the time so long as the 2.7.x branch is getting security updates. When the security updates stop, the move will finish. The reality is that those of us who have been working with Python for a long time now (10+ years) have already figured out reliable workflows to get around the most lacking aspects of the language in our domains of expertise. Or we have swapped out subsystems in other languages for cases where we absolutely cannot find workarounds. I get it. I'm in that boat. I understand that boat because I live in it. I can even understand why this project happened. Because hacking things you love to make them better for you as an individual is the heart and soul of what makes software development so great. What I absolutely cannot understand is why anyone (absent certain libraries needed) would start a new project on a deprecated branch of a language. And I don't understand why this is such a contentious issue specifically with Python. I don't hear any of my friends who work with C# or Go getting into arguments about how the latest version has failed or shouldn't have been rolled out. As much as Swift 3 has caused problems, I don't hear any of my iOS developer friends complaining about how that shouldn't have happened and trying to backport the good stuff into the 2.x branch. I genuinely don't understand this behavior in the Python community. * I do, however, suspect that it has something to do with the overall age of the community. Using Python has always been a matter of taste and style. I get that. Python is a language that makes explicit tradeoffs between performance and style. It is no shock to me that people who learned to love the language in its older form want it to stay that way. And I say this as someone who is closer to 40 than I am 30: we older folks in the industry need to fight against the stereotype that we can't or won't learn new tricks. Yes, there's a place for battle scars and pushing back against every new flavor-of-the-month stack that rehashes old problems in new ways. But obstinately sticking with stuff simply because it's what we know does all of us who are getting on in years a huge disservice. Getting a good gig as a software engineer in your 20s is not that difficult. Getting the same gig when you're pushing 40 and the hiring managers are still in their 20s is a lot harder. If you're making decisions to start new projects on old versions of any language, please, please, please, do all of us a favor: make sure that you are doing it for solid reasons and not simply because it's what you already know and are already comfortable with. * Because this post isn't long enough already, I have a second pet theory about the reluctant adopters. Python 3 is a _great_ language. It's not the same as Python 2. It makes different tradeoffs about styles and choices of expression from what Python 2 does because these things can and should change over time. I think that the expressive power of Python, the closeness to human language, and the ease of reading well-formed code have a lot to do with the resistance to Python 3. There are people (I'm one of them) who get really really picky about language in general. I think the Oxford comma is a necessity in almost every case. And I think people who casually omit it are stupid, shallow, non-thinking, drones who don't care about the history of language and don't care about precise meaning of words, and therefore don't care about me because they an't be arsed to toss a comma in a place that greatly clarifies meaning. I don't actually think all of that, but I'm closer to that than I am to not caring at all. And there are many like me. When you're dealing with a programming language with intent at its heart, people are going to take that in different ways. When you're dealing with a language that cares about whitespace and eschews braces and wants to limit brackets and just expose the pure logic of the program, people really are going to get fired up about print vs. print(). That's expected. And beautiful that so many people care that much. But as much as I lean towards prescriptivism and that rules are good for a language, even I have to admit that language evolves. But it usually evolves to be more inclusive and more expressive, not less. The really bad fights about languages in general revolve around what to include, not what to exclude. Because languages are exclusive by default. A counterpoint to my idea above that we are all just old and lazy, is this: that we really do genuinely care, and that we care for good reasons. But something has to give. We cannot refute the evolutionary pressure. Python 3 is as necessary for modern speakers of programs as a recent edition of a dictionary is in your preferred language. Yes, you can get by with something older, and you can even make yourself understood by most people who speak the language. But you are limiting your ability to express your intent when you make an intentional choice to refuse to adopt what the rest of the culture around you is doing. Aaaaaaand I'm done. Sorry for how long that was. I didn't intend that. It just sort of happened. If you read all the way to the end, let me know, and I'll upvote you. [0]: https://github.com/PyCQA/pycodestyle/issues/466 https://github.com/PyCQA/pycodestyle/issues/466
• jchassoul 10y ago
  Just don't call it Python 2.8
  • jchassoul 10y ago
    PLEASE don't call it Python 2.8 ...
• rebootthesystem 10y ago
  Hmmm. OK. This is a bad idea. My guess is the author will not be able to call this thing "Python", and for good reason. Should it exist? Sure. Why not? The nature of FOSS is that anyone can tinker with it and make it into whatever they dream. Go for it! Just don't call it Python. I use both 2.7 and 3.x. No drama. New projects go through a "Do we see any issues with 3.x?" phase where we try to list libraries we'll need and check for support. Not that difficult. I absolutely understand companies/people holding on to 2.7 for dear life. Converting a non-trivial working code-base would be costly and very difficult to debug if that code base doesn't have extensive test coverage (probably true of most). It would also be utterly irresponsible in most business cases. Most businesses don't have software developers sitting around doing nothing. Revenue comes from existing products and new features along with bug fixing. No customer of a software product will pay one dime for a company devoting a year to port their entire code-base to 3.x. Can you visualize that announcement? "We stopped delivering new features and fixing bugs a year ago. Instead we ported our entire product to Python 3.x. Today, a year later, we give you exactly what you were using a year ago. Enjoy!" Yeah. Exactly. The huge sucking sound you'll hear is that of customers leaving the company throughout an entire year of nothingness. In a dynamic free market competitors would eat you alive as you stop delivering features and fixes while they zoom right past you with a better offering to your customers. That said, sticking to 2.7 for the long haul --say, ten years from now-- will create the Python equivalent of old COBOL code still running in deep dark places within financial institutions. It will create codebases nobody wants to look at or touch. It will create codebases that will be anywhere from hard to impossible to support as libraries will surely evolve to support the 3.x and, eventually, 4.x branch. It is perfectly sensible for a company to, given today's realities, stick to 2.7. This is almost exactly the problem described in "The Innovator's Dilemma". Good management means focusing on delivering what your current customers are buying and want to buy. Unless they are clamoring for your product to use 3.x it could actually be really bad management to make the switch. The only way to do it correctly would be to hire a full parallel team of programmers to port the codebase while mirroring every single new feature and bug fix implemented as customer's needs are met. At some future point the two branches would achieve parity in function and reliability. This parity would allow seamlessly switching to the new codebase without damaging customer relationships. Of course, this would cost a ton of money for a non-trivial product and, at the end of the process, the company would probably have to fire one of the two teams. Pretty messy and costly in more than just financial terms, isn't it? I am not advocating either approach. Just saying I understand this from both engineering and business perspectives. People pushing others to just switch are doing so from a frame of reference devoid of any understanding of the realities of business. Most businesses are not about the technology, they are about what problem you solve for your customer. They don't care about "the geek stuff" behind the curtains. And rightly so. Live long and prosper.
• Animats 10y ago
  It's too bad someone didn't do this years ago. We could have avoided much pain.
• maxander 10y ago
  So when you see a project written in Python 2.8, you'll know that it contains lots of legacy code under active development by developers who are gung-ho about fancy language features, but that this team hasn't had the time/resources/gumption to do a code overhaul anytime in the past six years. And also that you yourself, and any users of your own project, will need to run it with this guy's own homebrewed version of Python in order to know it will behave correctly. Useful?
• Grue3 10y ago
  The worst thing about Python 3 are Python 3 fans. This very thread is a good indication. I'm pretty sure this guy is getting death threats right now.
• upofadown 10y ago
  I consider the fact that 2.7 isn't getting new features a good thing. After a point, every new feature takes away something from everything that came before.
• dagss 10y ago
  I see many people vigorously defending Py3 but I wonder how many of these have a paying-the-bills kind of job. Where you would look at the cost of porting a large project to Py3 and get an answer like half a million USD (easily). Do you go "of course we do that, that money is easily recouped with the added programmer productivity of Py3"? No chance. So the question is do you want to basically light that money on fire, or just keep your perfectly fine Py2.7 code running and maintained another few years. More discussions of the monetary value of programming languages please. What is "correct" or "right" isn't all that interesting to many, for good reasons. Kudos to this project and hope it can set us on a saner migration path to Py3. (Should totally change the name though.)
  • toyg 10y ago
    You can keep your py2.x code running, absolutely; but you cannot expect other people working for free to help you pay your bills. Honestly, the level of self-entitlement through all 2vs3 threads is staggering.
    • dagss 10y ago
      I don't want the CPython core devs to do anything different and are not angry with them at all. It is their pet and they can do what they want. I fully agree with what you say in that sense. But I do mind people saying in these discussions "you should all move to Py3 now or you are stupid/evil". No. There are legitimate reasons for staying with Py2.7 and embracing it. So I hope "Python 2.8" gets a cool name, perhaps even some funding from a company who wants to keep their Py2.7 code alive and invigorated, and the community part as friends. Is that self-entitlement in any sense? All I want is for people who I think have a huge blind spot to stop calling me ignorant for decisons I make about MY code. I totally don't expect core CPython devs help me out though.
      • toyg 10y ago
        > I don't want the CPython core devs to do anything different It's not just CPython, it's the Python specification of which CPython is the reference implementation. The specification couldn't move forward in significant ways without making some of the changes that came with Python 3. > All I want is for people who I think have a huge blind spot to stop calling me ignorant The level of vitriol in 2vs3 threads has been way too high from the start, because people always hate change. You are obviously free to do what you want, you always were. Don't mind the haters, but please don't be one either.
• greyman 10y ago
  Nobody should believe me, but I kind of expected something like this would happen. People just wants to keep using 2.7, and let the language evolve slowly over time, as is happening with PHP, for example. So if 2.7 development was officially stopped, someone will continue with it unofficially.
• StevePerkins 10y ago
  Haha... this is the most Python thread ever.
• rini17 10y ago
  The discussion is a nice overview how py3k crowd just steamrolls over any discussion that there are indeed inherent difficulties with forcing lossy conversion of imperfect outside input. See example in the fine manual: https://docs.python.org/3.7/library/urllib.request.html#examples https://docs.python.org/3.7/library/urllib.request.html#exam... You are only told "we know python.org uses utf-8 so just decode it as utf-8." No further discussion, no pointers are provided how to correctly fetch an URL with text content into a string. Even small convenience function that at least tries to look on Content-Type: header would help here! I am well aware that "in py2k it just worked" was mostly an illusion. But honestly, is the situation above an improvement?
• MaxfordAndSons 10y ago
  Slightly tangential, but: I've noticed an interesting parallel between the 2.7 / 3.x partisan divide, and the US political partisan divide. In both cases, as partisan passions have increased without relief, there's both A) an increasing unwillingness to agree on basic facts about reality essential to the debate, and B) increasing presumptions of bad faith on the part of their opponents. Examples of A in this discussion: - Disagreements about the degree of library support for 3.x - '' the ease/value of porting from 2 to 3 - '' the rate of industry adoption of 3 for new projects - '' the degree to which people are driven away from Python entirely because of the version situation Examples of B in this discussion: - Claims of paternalism on the part of GVR/ the PSF in pushing 3 - Claims of unreasonable/emotional attachment to 2 by partisan devs - Claims of willful distortion of facts by both sides (see A) - Claims that the writing is on the wall for 2, because usage of 3 is supposedly accelerating - Claims that the writing is on the wall for 3, because it's supposedly taken too long to drive not enough adoption It seems outrageous to suggest that the differences between 2 and 3 are anywhere near as significant as the differences between, say political conservatism and liberalism, and yet the level of partisanship seems nearly the same. How did it come to be like this?
  • nercht12 10y ago
    +1 I like how your comment stands out as being such a rational, non-aggressive observation in all this. I wish I had the answer for you, but I can't figure it out either. shrug Maybe some people are using this as an opportunity to vent the frustrations they've had with using the language (despite it being so loved, and ranked 3rd in most-used according to IEEE), and since there are two versions of the language instead of one, they can more readily create an object doomed for the epitome of their hatred, the sacrificial lamb going to the slaughter (sounds like something from a bizarre school of thought in psychology). You'd think it'd just be easier to let people do what works best for them. I'm sure many expect to take collateral damage from the differences in versions (imagine being a Python 3 fan and having to start working for a company that exclusively uses Python 2 or vice versa), but these people also readily accept working with languages with radically different designs and welcome in copy-cats (like Clojure is to other LISP-like languages). The important thing is that the language does what you need it to do. The name on the download link shouldn't make that much of a difference. The world has adapted to accepting Python 2 and Python 3 regardless of the bickering. There's room for "Python 2.8", even if it is poorly-named. I imagine there are probably dozens of Python 2.8s in existence - they just haven't been noticed by people here on HN. Besides, in about 3 months, we probably won't be hearing more about Python 2.8 anyways unless someone else decides to use it.
• naftaliharris 10y ago
  Author here. Imagine my surprise when I got back from a day of sightseeing (I'm on vacation in Spain) and saw that this had blown up. I had intended to "release" this project after New Years, after I'd gotten back and a week or two after 3.6 is released [1], and didn't expect this to get picked up since the project has been on Github for over a year (although inactive for much of that time) and since my blog usually doesn't get much traffic. A lot of people here have strong opinions about the name "Python 2.8". I don't mind changing it, and intend to do so, (https://github.com/naftaliharris/python2.8/issues/47 https://github.com/naftaliharris/python2.8/issues/47). I picked it initially since when talking with friends about this project it conveyed pretty darn immediately what the project is and does. I'd be very keen to hear people's suggestions for alternate names! For those of you with 2.7 codebases or projects, I'd be extremely interested in hearing about whether you were able to get this interpreter to run your code. Personally, the biggest challenges I've had so far are with dependencies that check for `sys.version_info[:2] == (2, 7)` as opposed to something like `sys.version_info[0] < 3`. But I'd be very interested in other people's experiences, particularly with larger codebases. [1] A minor and somewhat pedantic point: The interpreter I've been working on includes PEP 515 (underscores in numeric literals), which is new in 3.6. I didn't think it was right for me to "take credit" for this new feature before it was even out in Python 3.6. Obviously, the real credit for this feature existing (in 3.6 or in any interpreter) goes to the CPython core devs, and especially Georg Brandl.
  • eximius 10y ago
    Regardless of the detractors, I think this is brilliant work. All of the negativity around your project is over politics or subjective opinions based off of individual experience where they are lucky enough to work in environments on the bleeding edge. Keep up the good work, this could help a lot of people!
• slmyers 10y ago
  Is the xkcd Appropriate Standards strip appropriate here?
  • nercht12 10y ago
    Python xkcd: https://xkcd.com/353/ https://xkcd.com/353/ What's even ironic here is that the print command he used is Python 2 instead of Python agnostic. I wonder which version Randall Munroe would prefer, if either.
• BuckRogers 10y ago
  So it begins. The arrogance and stubbornness of the CPython dev team is starting to face the consequences we all knew were coming. If only they'd at least done unicode right. Gone with assume UTF-8 and kept the indistinction between bytes and unicode, more of us would be onboard.
• aftbit 10y ago
  Why did Python 3 not ship with from __past__ import bytestring_literals, loose_comparison, integer_division, ... ? Being able to upgrade one file at a time to Py3 would have made porting so much easier! I realize some things could be hard to support file-at-a-time, but others (like my examples) would obviously not. I've held off on porting the Py2 code that I'm responsible for because of the lack of total test coverage. I know that something tricky with unicode, None comparison, or the list->generator split will cause a failure in a weird, untested edge case. If I were making a numeric library, that'd be one thing. However, I mostly write complicated business logic API glue code that is hard to test without huge amounts of mocks. Also, this kind of thing gives me nightmares about porting: WSGI therefore defines two kinds of "string": "Native" strings (which are always implemented using the type named str ) that are used for request/response headers and metadata "Bytestrings" (which are implemented using the bytes type in Python 3, and str elsewhere), that are used for the bodies of requests and responses (e.g. POST/PUT input data and HTML page outputs). So according to the spec (!) WSGI headers MUST be `str` in Python 2 & 3, but that means that the semantic meaning of the types changes. How on earth am I supposed to write good code for working with headers (let alone mocking and testing) when I'm required to decode them in Python 2 but not in Python 3?
• yahyaheee 10y ago
  Please just spend your time porting things to python 3, this kind of work could spell the end for python
• Pica_soO 10y ago
  Program languages could be so great if it were not for those pesky users.
• woah 10y ago
  Why does Python have so many hilariously convoluted trials and tribulations over decades trying to upgrade their language when the JavaScript community is able to run smoothly across many different versions and many different interpreters simultaneously?
• davidmanescu 10y ago
  I hope I don't come across as too obtuse, but it might still make economical sense for the PSF to backpedal on their decision: even if Python3 is a good solution for the future, it's caused years of arguments and still hasn't been adopted by the majority[1]. Ridiculous as it might sound, that implies it would actually take less work to devise a path for Python2 that's backwards compatible but still has a future, and invest the time to backport all 3-only code, than it would to proceed with killing off 2 and porting everything over. It's also nothing more than everyone whose code is 2-only is being asked to do sometime in the future (they chose "the wrong competing standard" and have to pay the cost). Either way someone has to foot the bill for a unified Python but couldn't it just be that the early adopters of 3 could pay that cost if it saves updating (say) twice as much legacy code in favour of backporting the 3-only code? Of course, the future version of Python should be the best form of the language with the right features, and that's why it was decided to kill off 2, but if after this many years the initiative hasn't completely succeeded, there's always the option to reverse course. Heck, in the time until Python 2 is officially gone, maybe this new fork will evolve into a better language than 3 and still be backwards-compatible with 2! For now I'm sticking with 2.7 for as long as I can but will just accept it when the time comes. [1]: https://mobile.twitter.com/vlasovskikh/status/801720613312364544 https://mobile.twitter.com/vlasovskikh/status/80172061331236... for example (I don't think I've made a controversial claim here but could be wrong)