[Python-ideas] More "ensure*" packages

[Terry Reedy]

On 8/13/2015 1:06 PM, Steve Dower wrote:
> I'd like to propose expanding the list of 3rd-party packages we bundle
> and install by default. (Obviously this does not apply to platforms that
> repackage Python and can do whatever they want, but on Windows and Mac
> we are fully responsible for these.)
>
> Currently, we bundle pip (and some of its dependencies - let's avoid
> that particular discussion right now please, it's on python-dev) and
> install it by default in a way that lets users easily update to the
> latest version. Including pip in the standard library would lock users
> into a specific version for the lifetime of that Python version, which
> would be a bad thing.
>
>  From my point-of-view, this has been very successful in Python 2.7, 3.4
> and will also be successful in 3.5. For Python 3.6, I'd like to do a
> similar thing with:
>
> * requests

Not in stdlib, so easier availability is a plus

> * tkinter (including tcl/tk, IDLE, and other dependencies)

In stdlib, heavily used by beginners, who will not be helped by the 
change and who may possibly be harmed by reduced availability.

Why did you pick the tkinter group instead some obsolete and little used 
modules, such as asyncore and asynchat?

I think any discussion of breaking up the stdlib should wait until the 
new workflow is chosen and implemented.

> tkinter is worth more discussion :) For the remainder of this email,
> I'll use "tkinter" as shorthand to refer to Tcl, Tk, Tix, _tkinter,
> tkinter, idlelib/IDLE, PyDoc, turtledemo and any other dependencies or
> dependents that I missed.

turtle itself.

> In my experience, few Python scripts depend on or assume tkinter is
> available.

No person's experience is representative.  On Stackoverflow, tkinter has 
a higher rate of tkinter questions than for, say, requests or pil.  I 
suspect its usage is also higher than those modules among students 
learning Python.

 > tkinter is already an optional item in the Windows installer

I am pretty sure that this is due to the large size of tcl/tk.  This is, 
of course, less relevant now than 20 years ago.  The offline docs and 
test suite (/lib/test/) are also optional.

> (maybe Mac too? I don't know) and there are certainly installations of
> Python out there that don't have it. From this side, nothing would
> actually change by installing tkinter into site-packages rather than Lib.

There are multiple questions here: where is x developed, where is it 
installed from, and where is it installed to, and what is it installed 
with.  Educational machines tend to be as locked down as corporate 
machines.  Many places allow 'python and its stdlib' as a package, but 
no other python packages.  If such policies excludes installing into 
site-packages, then the proposed change is crippling.

[Shifting focus from 'tkinter' to Idle...]

> (One impact may be the start menu shortcuts for IDLE and PyDoc.

For students who are not allowed to use a console, the icons are essential.

> IDLE is already allowed to make enhancements in maintenance branches
> (https://www.python.org/dev/peps/pep-0434/),

PEP 434 formalized what had more or less been the practice for several 
years before.

> and we have recently
> received patches that are to be applied to *four* branches.

So what? This is not limited to Idle.  There are, of course, *four* 
branches because we have not dropped 2.7 and started 3.6 earlier than usual.

 > The freedom to enhance IDLE is greatly improved by making it
 > a PyPI installable package

Are you volunteering to do this? Pardon my skepticism, but you said 
yourself that you work at Microsoft on "a direct competitor to Idle".

> and disconnecting it from the stdlib's schedule.

You already explained above that the stdlib schedule is pretty much not 
an issue for Idle. And as you already know, Idle is already on track to 
get a makeover in the next year *with things as they are*.

Anyway, just as there are separate lists for other specialized topics, 
like packaging, time zones, and core workflow, there is a separate list, 
Idle-sig*, for discussing how to improve Idle. Anyone interested in this 
should join us there.

*mirrored on news.gmane.org as gmane.comp.python.idle with no 
mail.python.org subscription required.

-- 
Terry Jan Reedy