[Python-Dev] Language Summit notes

[Kristján Valur Jónsson]

> -----Original Message-----
> From: Nick Coghlan [mailto:ncoghlan at gmail.com]
> 
> > 2.       Feature enhancement to 2.8.  Take a robust and popular version of
> > python and add some of the language goodies that have been added to
> > 3.x and that don’t have an inherent 3.x aspect.  Yield from.  New exception
> model.
> > Stdlib enhancements such as futures.   The argument goes like this:  We
> have
> > a very popular platform out there with lots of momentum.  People want
> > incremental enhancements to it.  Why not give them what they want?
> > Bread and games and all that?  A Rockband cannot stay cooped up in a
> > studio producing experimental concept albums all the time.  That is death.
> > Sometimes it needs to go on tour and play old hits for the fans!
> 
> Do you know how much work a new Python 2.x release creates for people?
> All the redistributors have to update, books get outdated, a new wrinkle gets
> added to the compatibility matrix for everyone. A new Python 2.x release is
> simple untenable at this point in the transition
The key word here, "transition".  I’m not sure that everyone wants to transit.
This may be the core of the issue.   I know that this has been hashed to death before.  Never the less the pressure is there, I think and it would, I predict, be a crowd-pleaser.

> - it's a *massively* expensive way to achieve things that can be achieved
> more cheaply in other ways.
More cheaply from "our" point of view, perhaps.
> 
> Take yield from, for example. Hy is able to compile *LISP* syntax to Python
> AST structures. PEP 380 includes a semantic expansion of yield from in terms
> of yield. Is it *really* impossible to get "yield from"
> based code running in Python 2.6? Or have people just assumed it's not
> possible and never even tried, because the idea of using import hooks to
> backport syntax to earlier feature releases is too novel?

Some things are better done as language features than as complicated reverse hacks.
You keep saying that this and that can be done with add-on modules.  I think you underestimate the practical and psychological barrier towards those things.  Every new dependency on a package In some package directory is a new complication in a project.  It is something new you have t get, something requiing yet another virtualenv directory, something unblessed.
Another factor is the simply sheer size of Pypi by now.  How do you find things?  How do you even guess that things like "yield from" might be available as a package to pip install?  I know that this can be improved and tat there is work in process in doing that but the PyPi is still not core python and there is a gap that must be bridged for a user to start looking for solutions there.

> > 3.5 features
> >
> > When asked what should we aim for in 3.5, there were mostly some very
> > minor incremental changes suggested, IIRC.  In my opinion, the reason
> > 3.x has not caught on is that there is no real carrot there.  There is
> > no new vision, no killer feature.  Nothing that a programmer sees and
> > makes him say “Yeah! I want to program my next project using this feature,
> it will be super!”.
> 
> I *really* wish folks from North America, Europe and other regions where 8-
> bit encodings can handle their native language and where Anglicisation of
> terms to fit them into the ASCII identifier restriction poses no barrier to
> communication would stop trotting out this "no killer feature in Python 3"
> canard.
I intentionally didn't mention this because it is like the GIL.  It is a technical feature of the language, a refinement if you will.  But not a new thing in terms of language evolution.  Look, I have no disregard for the importance of this, myself coming from a non-ascii language.  I also worked on the internationalization of EVE, many years ago, and am familiar with the annoyance of implicit Unicode conversions.   I work in a company that uses unicode in all its products, new and old.  The other day a new stand alone service was developed.  I suggested to the developer that he might want to use Python 3 because it is unicode through and through.  He just shrugged, said it wasn't an issue.  He'll store the relevant database tables as unicode, get unicode out of the stuff, encode unicode in json and everything will just work.  While I'm not saying that the new model is not better (I think it is) it does come with some baggage, particularly in how it has been more cumbersome to work with bytes.  But anyway, this is why I didn"t mention unicode and why I don't count it as a killer feature.

 While it is *possible* to write internationalised and localised
> applications in it, Python 2's Unicode support is so broken that some people
> can't even run the interpreter from their home directory because it can't
> cope with their username. 
Years ago we implemented fixes to that for python 2.5.  core dev wasn't interested :).  

> If anyone is *ever* tempted to utter the words "Python 3 has no killer
> feature" without immediately following it up with the "for me"
> qualifier, please go read this post about the creation of a Portuguese version
> of Stack Overflow:
> http://blog.stackoverflow.com/2014/02/cant-we-all-be-reasonable-and-
> speak-english/
Look, unicode is important.  Just as having an automatic choke in a car is important.  Do you remember manual choke levers in cars?  I’m sure the Ford Falcon had one.  Removing the choke is a refinement.  But not a quantum leap.

> 
> Late last year, Alex Gaynor made the insightful observation that we write
> software either for the users we have or for the users we want.
> Python 3 is the software we're writing for the users we want. Python
> 2.7 long term maintenance, PyPy, standard library backports, transition
> libraries and tools, packaging ecosystem improvements, Python 3 features
> designed primarily to easy migration from Python 2, PyPI modules that run
> on both Python 2 & 3 - that's the software we and many other people are
> writing for the users we have.
> 
> >
> > 1.       Code blocks as a core language construct.  Re-implement context
> > managers as block executors.  We shouldn’t let details such as syntax
> > questions distract us.   That’s like saying that we can’t  eat spaghetti
> > because our Italian is so poor.
> 
> When it comes to blocks, the syntax isn't a distraction - it's the fundamental
> framing of what the construct is and how it should be used. How does a block
> get used to define a sorting key function? How does it get broadcast over a
> NumPy array? How does it get distributed to multiple threads, processes or
> greenlets, or passed to an IO scheduler? How does it differ from an ordinary
> closure? How does it relate to loops and other constructs?
> 
> There is a large existing constellation of concepts that blocks need to be
> fitted into, and any successful proposal for adding blocks to the language will
> require giving that process the respect and attention it deserves.

You're getting bogged down in implementation details, letting side issues distract you from the core goal.  We could for example start with a vertical slice.  Enable code blocks for context managers.  See how we solve the syntax (already done) and explore the possibilities that it gives us.  Then look at sorting functions.  One step at a time.  I'm sure we'll find a way, unless we are already convinced that it is impossible. 
But anyway, I mentioned code blocks because it is such an obvious thing to explore and has been an ongoing chestnut on python-dev for eons.


> This won't happen without a full usability study, but I've been speaking to
> Fernando Perez and Greg Wilson about some vague concepts for doing
> exactly that. I hope to be able to explore that possibility further at SciPy in
> July - Greg laments the lack of "evidence based language design" and I think
> the strong scientific presence in the Python community provides us with a
> genuine opportunity to move in that direction when it comes to controversial
> changes like code blocks.
The literature is full of them and there are languages out there that use them.  This isn't even pioneering CS :(

> 
> If people are genuinely interested in building and supporting the Python
> *community*, stop thinking about tinkering with the *language*.
This is python-dev.  It is about the *language*.  CPython is the reference implementation.
It is where most of that are passionate about the language operate. I'm trying to instill a passion for boldness here, to not be happy with letting the evolution of python die some beurocratic death.  I'm sure we can come up with ways of making Python continue to innovate, while still maintaining all this *community*.

> So folks looking to core development as the engine room of Python's growth
> are *looking in the wrong place*. We laid the foundation (and will continue
> to sustain and evolve it), but the real growth drivers have now moved
> further out to things like the work the PyPA is doing to make upstream
> packaging easier to consume, the work Travis Oliphant and others are doing
> to make the scientific Python stack easier to consume, the work Fernando
> Perez is coordinating around IPython and IPython notebook, the work Titus
> Brown et al are doing around reproducable science, the work Greg Wilson
> and Mozilla Science Labs are doing around Software Carpentry, the work Van
> Lindberg and others are putting into opening up the PSF, the work Jesse
> Noller has been driving around opening up python.org to more contributors,
> the work Jessica McKellar and more are doing around getting Python into
> high school curricula in the US, the work the Raspberry Pi Foundation are
> doing in the UK, the work around the core mentorship program, GSoC and
> the Gnome Outreach Program for Women, the work to build the regional
> network of Python conferences (I'm told we're currently running at a rate of
> something like 2 new PyCons per week!), the work folks like me, Guido,
> Steve Dower, Jesse and more are doing to better engage with corporate
> users and inviting them to more directly support the sustainability of the
> upstream Python community (on *our* terms), the work PyLadies is doing
> around education and outreach, the work Steve Holden is now doing around
> improving the ready availability of Python training courses, and on, and on,
> and on.
This is all super work, and laudable.  But I don't understand your point.  Because all this python related work is being done, does that mean that we, as core python developers, should not continue to innovate on the language? 
People have different interests and aspirations and everyone should be able to find a slot in our great community where he feels he can contribute at his best.
I have already mentioned C# above.  This is a language probably as big as Python.  Yet with every revision of it, it seems to adopt previously experimental language features into the language core, making it even more powerful.  At the same time, it is also being used by lots of people.  These need not be mutually exclusive goals, mass marked popularity and language innovation.

It's like Country and Western:  We can have both kinds.  Let's do it.  Let's have fun!

K