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

[Simon Kennedy]

On Tuesday, 14 April 2015 14:54:51 UTC+1, Andrew Barnert wrote:
>
> On Apr 14, 2015, at 05:14, Simon Kennedy <sffj... at gmail.com <javascript:>> 
> 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.
>
>
Or perhaps 'nebulous' might be better. However it is an 'ongoing thought 
experiment'. Not everything is fully fleshed out. I have no qualms in 
admitting that. I'm certainly prepared to scrap the whole lot but currently 
the discussions are occurring in isolation and this is my attempt to make 
some sense of them.

But I assume because you've commented on it you're not totally 
uninterested. 
 

> 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? 
>

You're right 'Types' was not the correct term. Is there some term for the 
things that you manipulate in your code as opposed to the things which 
perform the manipulation? Maybe 'operands'?

It was attempt to separate these 2 concepts.
 

>
> 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?
> p
> 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?
>
>
Not everything in the document is different from the way things currently 
are. It's an attempt to envision what it would all look like at version 
3.9.9

 

> 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?
>
>
Drop OSX? Yes, of course, it's a dying operating system. :-)

Again, not everything is complete. But I posted it because I believe the 
general concepts that I think could be better defined are outlined in the 
document. It would be hubris on may part if I thought that I would get 
everything right on the first pass. Parts need to be fleshed out but the 
concepts are there.
 

> 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?
>

A lowest common denominator. Yes, a dict (or maybe an OrderedDict). 
Configuration is for software to use. The aim would be to coalesce all the 
disparate sources of configuration data into a single structure available 
to the software.

If we have a set of rules that layer the following configuration sources 
and we end up with a dict that has the sections / items / values how the 
tool wants them.

     global, user, project, command line parameters, environment variables, 
...
 
The 'layeredconfig' distribution on PyPi does part of what the document 
proposes but does not appear to concern itself with standard location of 
config files or a standard mapping between environment variables for 
example.

But what if we defined a mapping between an environment variable name and a 
section/value in the resulting dict. Or the mapping between an environment 
variable name and a config file to parse and add to the dict.

And what if the location of global / user configuration files was defined 
then a user of the system would always know where they could find them

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... at python.org <javascript:>
> 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/20150415/4fb3eb0a/attachment.html>