<div dir="ltr"><br><br>On Tuesday, 14 April 2015 14:01:30 UTC+1, Steven D'Aprano  wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Well, you've certainly been meticulous :-)

<br>

<br>[...]

<br>> * Removing the notion of 'virtual' environments. Everything's just an

<br>> environment.

<br>

What's the difference?

<br></blockquote><div><br></div><div>Not a lot ;-) Merely a reduction in concepts by 1.</div><div><br></div><div>The question I asked myself when I thought about it is. Why 'virtual'? What's the conceptual difference between a standard Python install and a virtualenv (now that no-site-packages is the default.)? How does it help a Python user to distinguish between the two? Why do we have py.exe which finds a Python install but not a virtualenv?<br></div><div><br></div><div>So why not merge the Python install and the virtual environment into a single concept - Python Environments</div><div><br></div><div>Then we could have two tools</div><div><br></div><div>1. 'py' which finds and starts environments. (plus py could automatically find scripts in the bin / scripts / tools directories without having to add them to the path)</div><div>2. 'pyenv' which manages environments (create, list, show info, activate etc.)<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>

<br>> * Splitting the standard library in twain. stdlib = 'baselib' + 'extlib'.

>   - baselib = Enough to start up a Python environment / install pip.

<br>>   - extlib = The rest of the current stdlib. Changes more frequently than

<br>> the baselib.

<br>

<br>Hmmm. That would have consequences. Are you okay with abandoning large 

parts of the corporate, government and education sectors?

<br>

<br>The thing is, one of the reasons that Python is so successful is that it 

<br>is *batteries included*. That's been a selling point for 20 years. This 

<br>means that using only the standard library, you can be productive and 

<br>get real work done. This is important for people using a standard 

<br>operating environment, or in restricted networks with no access to the 

<br>internet, or in any scenario where people have to get approval before 

<br>they can use a particular software package. Not everyone is able to just 

<br>download arbitrary packages from the Internet and use them on the spur 

of the moment.

<br>

<br>With Python, they only need to get *one* package approved: "Can I 

<br>download Python and use it?" It might take six weeks to get approval, 

<br>but once you do, you have not just the core language, but a good 150+ 

solid, useful, powerful libraries (and a few not so good ones).

<br>

<br>With your Python 3.9.9, they get the core language, and a mechanism for 

<br>downloading from PyPI, which they are not allowed to do without 

<br>approval, on pain of dismissal. Or not able to do, because the corporate 

<br>network blocks it. And don't even think about sneaking it in via USB key 

<br>from home... So each and every package that needs to be downloaded from 

<br>PyPI could take six weeks to get approval before they can run "pip 

<br>install os".

<br>

<br>The thing is, the broader Python ecosystem is not just hackers on Linux 

<br>with control over their own machines. It includes people in schools 

<br>using locked-down SOEs, corporate users with restricted network access 

<br>or paranoid legal/IT departments, people in developing nations with 

unreliable internet access, and more.

<br>

<br></blockquote><div><br></div><div>The idea of the baselib + extlib is an attempt to address the desire to update parts of the stdlib faster than every Python release.</div><div><br></div><div>You would still get all the batteries included. When installing a new version of Python the extlib would be installed along with the baselib just not along side the baselib i.e. it would be in a separate on disk structure.</div><div><br></div><div>A new version of Python would be</div><div><br></div><div>* python.exe + baselib</div><div>* extlib on disk structure somewhere else</div><div><br></div><div>The pippin tool which manages the extlib can pull in updates to the on disk repository in a batch as and when the maintainer wants.</div><div>and the environment's maintainer can update the environment with the version they want.</div><div><br></div><div>Installation from the extlib disk structure to the current environment is 'just a copy' operation.</div><div><br></div><div><div>A difference then between a package on PyPi and in the extlib is only that the extlib is 'blessed' by the same people who have control of the Python releases.</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">

<br>> * A new tool called pippin to manage the extlib

<br>

<br>Does this actually exist, or have you picked it because the name is 

<br>cool? (It is a cool name.)

<br></blockquote><div><br></div><div>Almost everything in the document doesn't exist yet and this in no exception. I think being a Tolkien fan may have something to do with why I picked it.</div><div> </div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">

<br>(There is already a pippin on PyPI and github. I don't know if they are 

<br>the same project. The one of github claims to be experimental. Remember 

<br>that most experiments fail.)

<br>

<br>

<br>> * Formalising what a package index is

<br>

What do you mean?

<br>

<br></blockquote><div><br></div><div>I can envision a future where there are multiple Python Package Indexes.</div><div><br></div><div>* The cheeseshop for 'uncontrolled' packages.</div><div>* A company specific package index that only packages that have been signed by an administrator can be installed.</div><div>* Plus others</div><div><br></div><div>Plus indexes in various stages of development</div><div><br></div><div>* PyPi - The current version</div><div>* Warehouse - The next version</div><div>* devpi - a bleeding edge development version</div><div><br></div><div>If there are to be tools which can interface with all these then there should be a formal document. Does this exist? I could not find one. All I've found various PEPS which propose updates to the cheeseshop.</div><div><br></div><div>This along with the pypi tool completes the PyPi Trinity.</div><div> <br></div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">

> * Addressing a Python project's lifecycle.

<br>

Surely that will be different for every project?

<br>

<br></blockquote><div><br></div><div>Sort of, but every project must go through some of these stages.</div><div><br></div><div>Create, Design, Code, Build, Test, Create Distribution, Upload, Download, Install</div><div><br></div><div>Consistent configuration between each of these steps would be desirable would it not? Allowing the creation of tools to manage projects.</div><div><br></div><div>If we don't look at them as a whole then we'll probably end up with inconsistencies.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">

<br>> * Configuration handling

<br>

What about it?

<br>

<br></blockquote><div><br></div><div>Because it's a thing that could be much more consistent across Python software.</div><div><br></div><div>What do we store in config files and where do we store them</div><div><br></div><div>* Sections</div><div>* Item names</div><div>* Item values (either singular or in a list)</div><div>* Item types</div><div><br></div><div>All configuration file formats can handle these but there's no best practice. Why not formalise it?</div><div><br></div><div>Which directory should they go in? Again consistency is desirable. Surely we can come up with a 'blessed' set of locations?</div><div><br></div><div>Then document also attempts to address the layering of configurations across</div><div><br></div><div>* In Code</div><div>* Site config</div><div>* user config</div><div>* Environment variables</div><div>* Command line parameters</div><div> <br></div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> 

> * Removing the use of 'lib' suffixes from almost all packages.

<br>

Why?

<br>

<br></blockquote><div><br></div><div>Because it's my vision of a future and I like consistency ;-) The question for me is why is it used in some places in the stdlib and not in others? What purpose does it serve? If it's a good idea shouldn't every package in the stdlib have a lib suffix? About the only place I can see it being useful is importlib because there's already an import statement and you don't want to 'import import' in your code<br></div><div> </div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">

<br>> * Claiming any name in PyPi starting with 'py'

<br>

That's going to be *really unpopular*. What is the purpose behind that?

<br>

<br></blockquote><div><br></div><div>I'm also sure it would be really unpopular but see the start of my previous response.</div><div><br></div><div>As it's only a vision of a possible future I'm under no illusion that it's the answer to all Python's 'problems' but it's an attempt to group all the disparate discussions into a single document. My answers may almost all be wrong / unimplementable but the discussions on the mailing list so far seem isolated and this is my attempt to make sense of them all.</div><div><br></div><div><br></div><div>Regards</div><div>Simon</div></div>