[Python-ideas] Python 3.9.9 - The 'I Have A Dream' Version

[Andrew Barnert]

On Apr 14, 2015, at 05:14, Simon Kennedy <sffjunkie at gmail.com> wrote:
> 
> Call me a fool, but in the vein of the finest of half baked ideas, I present to you an idea that hasn't even decided on the shape of the tin yet.
> 
> Using a pseudo random selection of ideas set out in various forums
> 
> * python-dev
> * distutils-sig
> * python-ideas
> * import-sig
> 
> I present to you, in the linked PDF, a possible Python future.
> 
>     Python 3.9.9 - The 'I Have A Dream' Version
> 
> http://www.sffjunkie.co.uk/files/misc/Python%203.9.9.pdf
> http://www.sffjunkie.co.uk/files/misc/Python%203.9.9.xmind

Most of this document seems so ambiguous that it's hard to know how to comment on it.

For example, you've got a section called "Types" (which I picked arbitrarily because my PDF reader decided to start with the top right corner of the giant page 1), which lists the types as "int, bytes, string, float, list, tuple, named tuple, dict, ordered dict, set, frozenset, enum, class, module, generator, iterator, iterable, context manager, function".

What does that mean? 

A good number of these are builtin types in 3.5; the most obvious implication is that the rest of them should become builtin types in 3.9.9. But what would it mean for namedtuple to be a type instead of a type factory? How can "class" be a type? If iterable becomes a concrete type, does that mean classes that implement the __iter__ method are no longer iterables, just "iterable-like types" (and likewise for context manager)? What would be the benefit of renaming "str" to "string"? Does the fact that you've left out bool and NoneType and method mean those will no longer be builtin types in 3.9.9? Some of your type names have spaces--major syntax change to the language, or typo?

Or, if this doesn't mean any such thing, and is just an attempt to categorize the kinds of stuff that "type-related stuff" will have to deal with in 3.9.9, how is it any different from 3.5, which already has the same kinds stuff?

Picking another part of the page at random, you see to have a stuff that goes into detail about specific paths for Windows vs. FHS/XDG. Does this mean you want to drop Mac support, remove the ability to configure and install into /opt/local or ~, etc.? If not, does it mean anything at all?

Right above that, how do you expect to automatically work with every configuration file format, from .ini and .rc files to the Windows registry (but not Mac defaults...)? Does that mean you're going to provide some lowest-common-denominator API (a flat list of C-identifier-style string keys mapping to printable ASCII string values with no newlines seems to be about as flexible as you can get)? If not, what else could it mean to support every format?
> 
> my ongoing thought experiment on a Python future I would like to see. Because, is it not written
> 
>     If you don't know where you're going, how will you know when you get there.
> 
> Whether an infinite number of monkeys could shape this into reality may never be put to the test, but it's a start.
> Or it may not be. Or it may be a start and the end. The future's as tricksy as hobbitses sometimes.
> 
> Highlights include
> 
> * Python The
>   - Executable
>   - Language
>   - Library
>   - Tools
>   - Ecosystem
> 
> * Removing the notion of 'virtual' environments. Everything's just an environment.
> 
> * Splitting the standard library in twain. stdlib = 'baselib' + 'extlib'.
>   - baselib = Enough to start up a Python environment / install pip.
>   - extlib = The rest of the current stdlib. Changes more frequently than the baselib.
> 
> * A new tool called pippin to manage the extlib
> 
> * Formalising what a package index is
> 
> * Addressing a Python project's lifecycle.
> 
> * Configuration handling
> 
> * Removing the use of 'lib' suffixes from almost all packages.
> 
> * Claiming any name in PyPi starting with 'py'
> 
> And more.
> 
> I have aimed for
> 
> * Separation of concerns
> * Consistency in naming of tool commands and options.
> 
> Your thoughts are welcome.
> 
> Next steps are
> 
> * Add all relevant PEPs - both proposed and accepted.
> * Add all modules to either baselib, extlib or deletelib
> * Firm up stdlib / environment / config file locations (system / user, Windows / Linux / OSX)
> * Create outline of pip / twine code to see what can be put into external packages for re-use / removal from pip.
> * Create a filesystem structure for projects and configuration files / cookiecutter templates to achieve this.
> * Enhance definition of tools and propose code structures.
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150414/4514265e/attachment-0001.html>