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 <ncogh...@gmail.com> wrote:
> On 17 August 2014 12:43, Guido van Rossum <gu...@python.org> wrote:
> > On Sat, Aug 16, 2014 at 6:28 PM, Nick Coghlan <ncogh...@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,
> 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 | ncogh...@gmail.com | Brisbane, Australia
>
--
--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
