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 <steve@pearwood.info <mailto:steve@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 5000000, 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.

On Aug 16, 2014, at 7:43 PM, Guido van Rossum <guido@python.org> 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

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 <ncoghlan@gmail.com> wrote:

...

On Sat, Aug 16, 2014 at 6:28 PM, Nick Coghlan <ncoghlan@gmail.com> 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,

On 17 August 2014 12:43, Guido van Rossum <guido@python.org> wrote: 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 only software can largely assume UTF-16-LE, but anyone trying to integrate with both is going to have a far more interesting time of things (as we've discovered the hard way). That transition is the core thing that sometimes makes migrating from Python 2 to Python 3 non-trivial - even the changes to dict are relatively simple to address by comparison.

...

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?

I'm assuming there *will* be a 4.0 - I'd just like to see it be "the release after Python 3.9", rather than being spectacularly different from the preceding 3.x releases. That's similar to the way that the Linux kernel shifted to the 3.x series not because of any particular milestone, but just due to the sheer weight of accumulated changes relative to the early 2.x releases.

...

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?

Based on the examples of both Python 3 and Perl 6, I'd personally strongly advocate for such a project to be a new language with a different name, even if it was created and maintained by python-dev :)

...

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. :-)

Yeah, I'm not sure a PEP is the right way either. However, it seemed to get the point across for both PEP 404 ("no Python 2.8") and PEP 394 ("POSIX platforms: don't make /usr/bin/python refer to Python 3, you break things when you do that"), so I figured I'd at least raise the suggestion on this topic as well.

Cheers, Nick.

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

-- --Guido van Rossum (python.org/~guido)

On 17 August 2014 15:34, Nick Coghlan <ncoghlan@gmail.com> wrote:

On 17 August 2014 15:08, Guido van Rossum <guido@python.org> 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 | ncoghlan@gmail.com | Brisbane, Australia

On Sun, Aug 17, 2014 at 6:29 AM, Barry Warsaw <barry@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). 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)

On 18 August 2014 11:14, Donald Stufft <donald@stufft.io> 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 | ncoghlan@gmail.com | Brisbane, Australia

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

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