Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
Am 18.08.14 08:45, schrieb Nick Coghlan: > It's certainly the one that has caused the most churn in CPython and > the standard library - the ripples still haven't entirely settled on > that front :) For people porting their libraries and applications, the challenge is often even bigger: they need to learn a new programming concept. For many developers, it is a novel idea that character strings are not just bytes. A similar split is in the number types (integers vs. floats), but most developers have learned the distinction when they learned programming. That a text file is not a file that contains text (but bytes interpreted as text) is surprising. In addition, you also have to learn a lot of facts (what is the ASCII encoding, what is the iso-8859-1 encoding, what is UTF-8 (and how does it differ from Unicode)). When you have all that understood, you *then* run into the design choices to be made for your software. > > I think Guido's right that there's also a "death of a thousand cuts" > aspect for large existing code bases, though, especially those that > are lacking comprehensive test suites. I think the second big challenge is "my dependencies are not ported to Python 3". There is little you can do about it, short of porting the dependencies yourself (fortunately, Python and most of its libraries are free software). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On 8/20/2014 8:27 PM, Joseph Martinot-Lagarde wrote: The pain was even bigger because in addition to the change in underlying types, the names of the types were not compatible between the python versions. I often try to write compatible code between python2 and 3, and I can't use "str" because it has not the same meaning in both versions, I can not use "unicode" because it disappeared in python3, And bridge library should have the equivalent of if 'py3': unicode = str I can't use "byte" because it doesn't exist in python2. 2.7 (and 2.6?) already has if 'py2': bytes = str and I presume bridge libraries targeted before that was added include it also. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
Le 18/08/2014 03:02, Guido van Rossum a écrit : On Sun, Aug 17, 2014 at 6:29 AM, Barry Warsaw mailto:ba...@python.org>> wrote: On Aug 16, 2014, at 07:43 PM, Guido van Rossum wrote: >(Don't understand this to mean that we should never deprecate things. >Deprecations will happen, they are necessary for the evolution of any >programming language. But they won't ever hurt in the way that Python 3 >hurt.) It would be useful to explore what causes the most pain in the 2->3 transition? IMHO, it's not the deprecations or changes such as print -> print(). It's the bytes/str split - a fundamental change to core and common data types. The question then is whether you foresee any similar looming pervasive change? [*] I'm unsure about what's the single biggest pain moving to Python 3. In the past I would have said that it's for sure the bytes/str split (which both the biggest pain and the biggest payoff). The pain was even bigger because in addition to the change in underlying types, the names of the types were not compatible between the python versions. I often try to write compatible code between python2 and 3, and I can't use "str" because it has not the same meaning in both versions, I can not use "unicode" because it disappeared in python3, and I can't use "byte" because it doesn't exist in python2. Add __str__ and __unicode__ to the mix and then you get the real pain. Actually "str" is still usefull in the cases where a library is byte-only in python2 and unicode-only in python3 (hello, locale.setlocale()). Joseph ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
Le 18/08/2014 13:22, Mark Dickinson a écrit : [Moderately off-topic] On Sun, Aug 17, 2014 at 3:39 AM, Steven D'Aprano mailto:st...@pearwood.info>> wrote: I used to refer to Python 4000 as the hypothetical compatibility break version. Now I refer to Python 5000. I personally think it should be Python 500, or Py5M. When we come to create the mercurial branch, that should of course, following tradition, be called p5ym. I would suggest "NaV", for "not-a-version". It would compare greater than all other version numbers (in the spirit of Numpy's "not-a-time", slightly tweaked). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
[Moderately off-topic] On Sun, Aug 17, 2014 at 3:39 AM, Steven D'Aprano wrote: > I used to refer to Python 4000 as the hypothetical compatibility break > version. Now I refer to Python 5000. > I personally think it should be Python 500, or Py5M. When we come to create the mercurial branch, that should of course, following tradition, be called p5ym. -- Mark ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On Aug 17, 2014, at 06:02 PM, Guido van Rossum wrote: >I'm unsure about what's the single biggest pain moving to Python 3. In the >past I would have said that it's for sure the bytes/str split (which both >the biggest pain and the biggest payoff). > >But if I look carefully into the soul of teams that are still on 2.7 (I >know a few... :-), I think the real reason is that Python 3 changes so many >different things, you have to actually understand your code to port it >(unlike with minor version transitions, where the changes usually spike in >one specific area, and you can leave the rest to normal attrition and >periodic maintenance). The latter is a good point, and sometimes it's a huge challenge to understand the code being ported. A good test suite (and dare I say, doctests :) help a lot with this. I've ported a ton of stuff, and failed at a few. I think all the little changes are mostly tractable, and we've assembled a pretty good stack of documents to help[*]. Sometimes a seemingly easy and mechanical port will produce odd failures, where more domain expertise needs to be brought to bear to get just the right bilingual invocation. But if the underlying code does not itself have a clear bytes/str distinction, then you're doomed. One of my failures was a Python binding for a large C++ project that deeply conflated data and text. Another was a pure Python library that essentially did the same. In both cases, I ended up in a situation where some core types could be neither str nor bytes without some part of the test suite failing miserably. Those are the types of projects that largely get left unported since it's much harder to justify the costs vs. benefits. Cheers, -Barry [*] https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On 18 August 2014 11:14, Donald Stufft wrote: > On Sun, Aug 17, 2014, at 09:02 PM, Guido van Rossum wrote: >> I'm unsure about what's the single biggest pain moving to Python 3. In the >> past I would have said that it's for sure the bytes/str split (which both >> the biggest pain and the biggest payoff). >> >> But if I look carefully into the soul of teams that are still on 2.7 (I know >> a few... :-), I think the real reason is that Python 3 changes so many >> different things, you have to actually understand your code to port it >> (unlike with minor version transitions, where the changes usually spike in >> one specific area, and you can leave the rest to normal attrition and >> periodic maintenance). >> > > In my experience bytes/str is the single biggest change that causes the > most problems. Most of the other changes can be mechanically transformed > and/or papered over using helpers like six. The bytes/str change is the > main one that requires understanding code and where it requires a > serious untangling of things in code bases where str/bytes are freely > used intechangingbly. Often times this requires making a decision about > what *should* be bytes or str as well which requires having some deep > knowledge about the APIs in question too. It's certainly the one that has caused the most churn in CPython and the standard library - the ripples still haven't entirely settled on that front :) I think Guido's right that there's also a "death of a thousand cuts" aspect for large existing code bases, though, especially those that are lacking comprehensive test suites. By definition, existing large Python 2 applications are OK with the restrictions imposed by Python 2, and we're deliberately not forcing the issue by halting Python 2 maintenance. That's where Steve Dower's idea of being able to progressively declare a code base "Python 3 compatible" on a file by file basis and have some means of programmatically enforcing that is interesting - it opens the door to "opportunistic and incremental" porting, where modules are progressively updated to run on both, until an application reaches a point where it can switch to Python 3 and leave Python 2 behind. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On Sun, Aug 17, 2014, at 09:02 PM, Guido van Rossum wrote: > On Sun, Aug 17, 2014 at 6:29 AM, Barry Warsaw wrote: >> On Aug 16, 2014, at 07:43 PM, Guido van Rossum wrote: >> >> >(Don't understand this to mean that we should never deprecate things. >> >Deprecations will happen, they are necessary for the evolution of any >> >programming language. But they won't ever hurt in the way that Python 3 >> >hurt.) >> >> It would be useful to explore what causes the most pain in the 2->3 >> transition? IMHO, it's not the deprecations or changes such as print -> >> print(). It's the bytes/str split - a fundamental change to core and common >> data types. The question then is whether you foresee any similar looming >> pervasive change? [*] > > I'm unsure about what's the single biggest pain moving to Python 3. In the > past I would have said that it's for sure the bytes/str split (which both the > biggest pain and the biggest payoff). > > But if I look carefully into the soul of teams that are still on 2.7 (I know > a few... :-), I think the real reason is that Python 3 changes so many > different things, you have to actually understand your code to port it > (unlike with minor version transitions, where the changes usually spike in > one specific area, and you can leave the rest to normal attrition and > periodic maintenance). > In my experience bytes/str is the single biggest change that causes the most problems. Most of the other changes can be mechanically transformed and/or papered over using helpers like six. The bytes/str change is the main one that requires understanding code and where it requires a serious untangling of things in code bases where str/bytes are freely used intechangingbly. Often times this requires making a decision about what *should* be bytes or str as well which requires having some deep knowledge about the APIs in question too. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On Sun, Aug 17, 2014 at 6:29 AM, Barry Warsaw wrote: > On Aug 16, 2014, at 07:43 PM, Guido van Rossum wrote: > > >(Don't understand this to mean that we should never deprecate things. > >Deprecations will happen, they are necessary for the evolution of any > >programming language. But they won't ever hurt in the way that Python 3 > >hurt.) > > It would be useful to explore what causes the most pain in the 2->3 > transition? IMHO, it's not the deprecations or changes such as print -> > print(). It's the bytes/str split - a fundamental change to core and > common > data types. The question then is whether you foresee any similar looming > pervasive change? [*] > I'm unsure about what's the single biggest pain moving to Python 3. In the past I would have said that it's for sure the bytes/str split (which both the biggest pain and the biggest payoff). But if I look carefully into the soul of teams that are still on 2.7 (I know a few... :-), I think the real reason is that Python 3 changes so many different things, you have to actually understand your code to port it (unlike with minor version transitions, where the changes usually spike in one specific area, and you can leave the rest to normal attrition and periodic maintenance). -Barry > > [*] I was going to add a joke about mandatory static type checking, but > sometimes jokes are blown up into apocalyptic prophesy around here. ;) > Heh. :-) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On Aug 16, 2014, at 07:43 PM, Guido van Rossum wrote: >(Don't understand this to mean that we should never deprecate things. >Deprecations will happen, they are necessary for the evolution of any >programming language. But they won't ever hurt in the way that Python 3 >hurt.) It would be useful to explore what causes the most pain in the 2->3 transition? IMHO, it's not the deprecations or changes such as print -> print(). It's the bytes/str split - a fundamental change to core and common data types. The question then is whether you foresee any similar looming pervasive change? [*] -Barry [*] I was going to add a joke about mandatory static type checking, but sometimes jokes are blown up into apocalyptic prophesy around here. ;) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On 08/17/2014 03:28 AM, Nick Coghlan wrote: I've seen a few people on python-ideas express the assumption that there will be another Py3k style compatibility break for Python 4.0. I've also had people express the concern that "you broke compatibility in a major way once, how do we know you won't do it again?". Why not just allow those changes that can be automatically changed by a tool/script applied on the code (a la go, 2to3, 3.Ato3.B, ...)? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On 17 August 2014 15:34, Nick Coghlan wrote: > On 17 August 2014 15:08, Guido van Rossum wrote: >> I think this would be a great topic for a blog post. Once you've written it >> I can even bless it by Tweeting about it. :-) > > Sounds like a plan - I'll try to put together something coherent this week :) OK, make that "this afternoon": http://www.curiousefficiency.org/posts/2014/08/python-4000.html :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On 17 August 2014 15:08, Guido van Rossum wrote: > I think this would be a great topic for a blog post. Once you've written it > I can even bless it by Tweeting about it. :-) Sounds like a plan - I'll try to put together something coherent this week :) > PS. Why isn't PEP 387 accepted yet? Not sure - it mostly looks correct to me. I suspect it just fell off the radar since it's a "describe what we're already doing anyway" kind of document. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
I think this would be a great topic for a blog post. Once you've written it I can even bless it by Tweeting about it. :-) PS. Why isn't PEP 387 accepted yet? On Sat, Aug 16, 2014 at 8:48 PM, Nick Coghlan wrote: > On 17 August 2014 12:43, Guido van Rossum wrote: > > On Sat, Aug 16, 2014 at 6:28 PM, Nick Coghlan > wrote: > >> I've also had people express the concern that "you broke compatibility > >> in a major way once, how do we know you won't do it again?". > > > > > > Well, they won't, really. You can't predict the future. But really, > that's a > > pretty poor way to say "please don't do it again." > > > > I'm not sure why, but I hate when someone starts a suggestion or a > question > > with "why doesn't Python ..." and I have to fight the urge to reply in a > > flippant way without answering the real question. (And just now I did it > > again.) > > > > I suppose this phrasing may actually be meant as a form of politeness, > but > > to me it often sounds passive-aggressive, pretend-polite. (Could it be a > > matter of cultural difference? The internet is full of broken English, my > > own often included.) > > I don't mind it if the typical answers are accepted as valid: > > * "because it has these downsides, and those are considered to > outweigh the benefits" > * "because it's difficult, and it never bothered anyone enough for > them to put in the work to do something about it" > > Those aren't always obvious, especially to folks that don't have a lot > of experience with long lived software projects (I had only just > started high school when Python was first released!), so I don't mind > explaining them when I have time. > > >> Both of those contrast strongly with Guido's stated position that he > >> never wants to go through a transition like the 2->3 one again. > > > > Right. What's more, when I say that, I don't mean that you should wait > until > > I retire -- I think it's genuinely a bad idea. > > Absolutely agreed - I think the Unicode change was worthwhile (even > with the impact proving to be higher than expected), but there isn't > any such fundamental change to the data model lurking for Python 3. > > > I also don't expect that it'll be necessary -- in fact, I am counting on > > tools (e.g. static analysis!) to improve to the point where there won't > be a > > reason for such a transition. > > The fact that things like Hylang and MacroPy can already run on the > CPython VM also shows that other features (like import hooks and the > AST compiler) have evolved to the point where the Python data model > and runtime semantics can be more effectively decoupled from syntactic > details. > > > (Don't understand this to mean that we should never deprecate things. > > Deprecations will happen, they are necessary for the evolution of any > > programming language. But they won't ever hurt in the way that Python 3 > > hurt.) > > Right. I think Python 2 has been stable for so long that I sometimes > wonder if folks forget (or never knew?) we used to deprecate things > within the Python 2 series as well, such that code that ran on Python > 2.x wasn't necessarily guaranteed to run on Python 2.(x+2). "Never > deprecate anything" is a recipe for unbounded growth in complexity. > > Benjamin has made a decent start on documenting that normal > deprecation process in PEP 387, so I'd also suggest refining that a > bit and getting it to "Accepted" as part of any explicit "Python 4.x > won't be as disruptive as 3.x" clarification. > > >> no plans to create a Python 2.8 release. Would it be worth writing a > >> similarly explicit "not an option" PEP explaining that the regular > >> deprecation and removal process (roughly documented in PEP 387) is the > >> *only* deprecation and removal process? It could also point to the > >> fact that we now have PEP 411 (provisional APIs) to help reduce our > >> chances of being locked indefinitely into design decisions we aren't > >> happy with. > >> > >> If folks (most significantly, Guido) are amenable to the idea, it > >> > >> shouldn't take long to put such a PEP together, and I think it could > >> help reduce some of the confusions around the expectations for Python > >> 4.0 and the evolution of 3.x in general. > > > > But what should it say? > > The specific things I was thinking we could point out were: > > - PEP 387, documenting the normal deprecation process that existed > even in Python 2 > - highlighting the increased preference for "documented deprecation > only" in cases where maintaining something isn't actively causing > problems, there are just better alternatives now available > - PEP 411, the (still relatively new) provisional API concept > - PEP 405, adding pyvenv as a standard part of Python > - PEP 453, better integrating PyPI into the recommended way of working > with the language > > Those all help change the way the language evolves, as they reduce the > pressure to rush things into the standard library before they're > ready, while at the same
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On 17 August 2014 12:43, Guido van Rossum wrote: > On Sat, Aug 16, 2014 at 6:28 PM, Nick Coghlan wrote: >> I've also had people express the concern that "you broke compatibility >> in a major way once, how do we know you won't do it again?". > > > Well, they won't, really. You can't predict the future. But really, that's a > pretty poor way to say "please don't do it again." > > I'm not sure why, but I hate when someone starts a suggestion or a question > with "why doesn't Python ..." and I have to fight the urge to reply in a > flippant way without answering the real question. (And just now I did it > again.) > > I suppose this phrasing may actually be meant as a form of politeness, but > to me it often sounds passive-aggressive, pretend-polite. (Could it be a > matter of cultural difference? The internet is full of broken English, my > own often included.) I don't mind it if the typical answers are accepted as valid: * "because it has these downsides, and those are considered to outweigh the benefits" * "because it's difficult, and it never bothered anyone enough for them to put in the work to do something about it" Those aren't always obvious, especially to folks that don't have a lot of experience with long lived software projects (I had only just started high school when Python was first released!), so I don't mind explaining them when I have time. >> Both of those contrast strongly with Guido's stated position that he >> never wants to go through a transition like the 2->3 one again. > > Right. What's more, when I say that, I don't mean that you should wait until > I retire -- I think it's genuinely a bad idea. Absolutely agreed - I think the Unicode change was worthwhile (even with the impact proving to be higher than expected), but there isn't any such fundamental change to the data model lurking for Python 3. > I also don't expect that it'll be necessary -- in fact, I am counting on > tools (e.g. static analysis!) to improve to the point where there won't be a > reason for such a transition. The fact that things like Hylang and MacroPy can already run on the CPython VM also shows that other features (like import hooks and the AST compiler) have evolved to the point where the Python data model and runtime semantics can be more effectively decoupled from syntactic details. > (Don't understand this to mean that we should never deprecate things. > Deprecations will happen, they are necessary for the evolution of any > programming language. But they won't ever hurt in the way that Python 3 > hurt.) Right. I think Python 2 has been stable for so long that I sometimes wonder if folks forget (or never knew?) we used to deprecate things within the Python 2 series as well, such that code that ran on Python 2.x wasn't necessarily guaranteed to run on Python 2.(x+2). "Never deprecate anything" is a recipe for unbounded growth in complexity. Benjamin has made a decent start on documenting that normal deprecation process in PEP 387, so I'd also suggest refining that a bit and getting it to "Accepted" as part of any explicit "Python 4.x won't be as disruptive as 3.x" clarification. >> no plans to create a Python 2.8 release. Would it be worth writing a >> similarly explicit "not an option" PEP explaining that the regular >> deprecation and removal process (roughly documented in PEP 387) is the >> *only* deprecation and removal process? It could also point to the >> fact that we now have PEP 411 (provisional APIs) to help reduce our >> chances of being locked indefinitely into design decisions we aren't >> happy with. >> >> If folks (most significantly, Guido) are amenable to the idea, it >> >> shouldn't take long to put such a PEP together, and I think it could >> help reduce some of the confusions around the expectations for Python >> 4.0 and the evolution of 3.x in general. > > But what should it say? The specific things I was thinking we could point out were: - PEP 387, documenting the normal deprecation process that existed even in Python 2 - highlighting the increased preference for "documented deprecation only" in cases where maintaining something isn't actively causing problems, there are just better alternatives now available - PEP 411, the (still relatively new) provisional API concept - PEP 405, adding pyvenv as a standard part of Python - PEP 453, better integrating PyPI into the recommended way of working with the language Those all help change the way the language evolves, as they reduce the pressure to rush things into the standard library before they're ready, while at the same time giving us a chance to publish "not quite ready to be locked down" features for very broad feedback. I'd also point out that the "variable encodings" to "Unicode" transition for text handling is an industry wide issue, one which even operating systems are still struggling with in some cases. POSIX-only software that only needs to run on modern platforms can assume UTF-8, while modern Windows and Java
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On Aug 16, 2014, at 7:43 PM, Guido van Rossum wrote: > But can we really say there won't be a 4.0? Never? Why not? Who is to say > that at some point some folks won't be going off on their own to design a > whole new language and name it Python 4, following Larry Wall's Perl 6 > example? If they ever do, please make them not follow the Perl 6 example! -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On Aug 16, 2014, at 6:28 PM, Nick Coghlan wrote: > I've seen a few people on python-ideas express the assumption that > there will be another Py3k style compatibility break for Python 4.0. Whenever I mention Python 4 or PEP 4000, it’s always a joke. However, saying upfront that we will never break compatibility is a bold statement. Technically even introducing new syntax breaks compatibility. Not to mention fixing long-lasting bugs. So you’d need to split hairs just defining what we mean by a “major compatibility break”. Worse, if we ever did a change that we feel is within the bounds of the contract, you’d have someone pointing at that PEP saying that they feel we broke the contract. Splitting hairs again. PEP 404 was necessary for some people/organizations to move on. I fail to see how PEP 4000 (or rather PEP 4004? ;-)) would be useful in that context. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On Sat, Aug 16, 2014 at 6:28 PM, Nick Coghlan wrote: > I've seen a few people on python-ideas express the assumption that > there will be another Py3k style compatibility break for Python 4.0. > There used to be only joking references to 4.0 or py4k -- how things have changed! I've seen nothing that a gentle correction on the list couldn't fix though. > I've also had people express the concern that "you broke compatibility > in a major way once, how do we know you won't do it again?". > Well, they won't, really. You can't predict the future. But really, that's a pretty poor way to say "please don't do it again." I'm not sure why, but I hate when someone starts a suggestion or a question with "why doesn't Python ..." and I have to fight the urge to reply in a flippant way without answering the real question. (And just now I did it again.) I suppose this phrasing may actually be meant as a form of politeness, but to me it often sounds passive-aggressive, pretend-polite. (Could it be a matter of cultural difference? The internet is full of broken English, my own often included.) > Both of those contrast strongly with Guido's stated position that he > never wants to go through a transition like the 2->3 one again. > Right. What's more, when I say that, I don't mean that you should wait until I retire -- I think it's genuinely a bad idea. I also don't expect that it'll be necessary -- in fact, I am counting on tools (e.g. static analysis!) to improve to the point where there won't be a reason for such a transition. (Don't understand this to mean that we should never deprecate things. Deprecations will happen, they are necessary for the evolution of any programming language. But they won't ever hurt in the way that Python 3 hurt.) > Barry wrote PEP 404 to make it completely explicit that python-dev had > no plans to create a Python 2.8 release. Would it be worth writing a > similarly explicit "not an option" PEP explaining that the regular > deprecation and removal process (roughly documented in PEP 387) is the > *only* deprecation and removal process? It could also point to the > fact that we now have PEP 411 (provisional APIs) to help reduce our > chances of being locked indefinitely into design decisions we aren't > happy with. > > If folks (most significantly, Guido) are amenable to the idea, it > shouldn't take long to put such a PEP together, and I think it could > help reduce some of the confusions around the expectations for Python > 4.0 and the evolution of 3.x in general. > But what should it say? It's easy to say there won't be a 2.8 because we already have 3.0 (and 3.1, and 3.2, and ...). But can we really say there won't be a 4.0? Never? Why not? Who is to say that at some point some folks won't be going off on their own to design a whole new language and name it Python 4, following Larry Wall's Perl 6 example? I think it makes sense to occasionally remind the more eager contributors that we want the future to come gently (that's not to say in our sleep :-). But I'm not sure a PEP is the best form for such a reminder. Even the Pope has a Twitter account. :-) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On Sun, Aug 17, 2014 at 11:28:48AM +1000, Nick Coghlan wrote: > I've seen a few people on python-ideas express the assumption that > there will be another Py3k style compatibility break for Python 4.0. I used to refer to Python 4000 as the hypothetical compatibility break version. Now I refer to Python 5000. > I've also had people express the concern that "you broke compatibility > in a major way once, how do we know you won't do it again?". Even languages with ISO standards behind them and release schedules measured in decades make backward-incompatible changes. For example, I see that Fortran 95 (despite being classified as a minor revision) deleted at least six language features. To expect Python to never break compatibility again is asking too much. But I think it is fair to promise that Python won't make *so many* backwards incompatible changes all at once again, and has no concrete plans to make backwards incompatible changes to syntax in the foreseeable future. (That is, not before Python 5000 :-) [...] > If folks (most signficantly, Guido) are amenable to the idea, it > shouldn't take long to put such a PEP together, and I think it could > help reduce some of the confusions around the expectations for Python > 4.0 and the evolution of 3.x in general. I think it's a good idea, so long as there's no implied or explicit promise that Python language is now set in stone never to change. -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
