[Python-3000] pimp; restructuring the standard library

[Brett Cannon]

On 6/28/07, tav <tav at espians.com> wrote:
> > Indeed, I'm also wary of breaking backward compatibility of unittest
> > or doctest in Python 3.0, because that will make it even harder to
> > port code over.  How will 2.x users run their existing test suites to
> > verify their code has been ported correctly, if they can't keep using
> > unittest?  As it is, they'll have to run them through 2to3, which
> > AFAIK doesn't do doctests currently.
>
> Ah, wasn't suggesting dumping the unittest module. Just that tests in
> the "standard library" should be doctest-based as these are much nicer
> and more useful!

But that is your opinion.  I personally prefer unittest and find them
just as useful.

If you want to get more doctest usage then you can convert some tests
over from the old stdout-comparison style to doctest.

>
> > A strong -1 on any import system that breaks down the current strict
> > separation between module names and module *locations*.  Too many
> > people confuse these concepts already, and we already have a nicely
> > field-tested mechanism for specifying locations and turning them into
> > importer objects.
>
> I agree with your -1.
>
> Let me rephrase that as being able to use any character in a str for
> import as opposed to the current limited set in 2.x. I understand that
> python literals are much broader in 3.0, how does that impact import?
>

You would need to change the grammar to get this to work.  And at that
point I would say you are better off developing a function to handle
the import than tweaking the grammar.

> > >* Authentication of sources with configurable crypto.
> > >
> > >* Full integration with setuptools + eggs.
> > >
> > >* Pluggable integration support for version control systems like svn/bzr.
> > >
> > >* Builtin versioning support for modules.
> > >
> > >* Live-update of modules/code support (in the vein of Erlang).
> > >
> > >* Rewrite of standard library to be more adaptable, concurrent, and
> > >pertaining to object capability. This way, we can have a secure,
> > >composable and parallelisable standard library!
> >
> > Um, and who are you volunteering to do all this work?  i.e., "you and
> > what army?"  :)
>
> Well, all that code being added to PyPi and the ASPN Python cookbook
> ain't being done by imagination alone... ;p
>
> Seriously, with:
>
> a). clear 'lead by example' initial set of how modules should work
> (with the above mentioned feature sets)

What is that supposed to mean?  Modules work how they work.  If you
are after specific style guidelines in terms of structure you are not
going to get one since each module has their own needs.  And taking
volunteer code already is hard enough; forcing a specific structure
just makes getting help that much harder.

>
> b). a provisional incentive model (say, via a gift economy model for
> all those who have contributed to the standard library)
>

Are we going to give gifts to everyone who has already contributed,
with interest?  And where is this money coming from?

I just see people tossing stuff at us just to get the money, and I
don't want that.

> c). a simple hook in the importer which keeps track of modules/code is
> used, which is used to remunerate the army (if anyone ever contributes
> financially to it) ;p
>

So you want every execution of a Python program to know who
contributed code to its execution?  It's called Misc/ACKS.

> > My thought is that you've just proposed several major PEPs that are
> > already too late for Python 3.0 and would probably have been rejected
> > or deferred anyway.
>
> I understood that issues relating to the standard library were still
> not fixed-in-stone for python 3.0?
>

Right, but that is mostly the reorganization, renaming, etc.  It does
not include changes to how import works, etc. that would require a
PEP.

> > I also think it's more likely that your ideas would find more
> > interest/support with the PyPy project than with mainline Python, as
> > some of them at least vaguely resemble some things they are working
> > on, and/or would be easier to implement using PyPy object spaces.
>
> This is definitely true. But I want to see all this in Python 3.0...

=)  Well, everyone wants to see everything they want in the next
version of Python.  Even core developers don't always get what they
want in a release.

-Brett