Re: [Python-Dev] asdl.py and Python-ast.[hc]

2013-09-27 Thread Antoine Pitrou 
Le Thu, 26 Sep 2013 10:28:46 -0400,
Benjamin Peterson  a écrit :
> 2013/9/26 Eli Bendersky :
> > Hi All,
> >
> > Earlier this morning I had a slight tackle with a couple of the 3.4
> > bots (sorry everyone!). I fixed some problems in asdl.py -
> > http://hg.python.org/cpython/rev/21d46e3ae60c - and used the 'with'
> > statement. Some bots don't have Python 2.6+ and couldn't bootstrap
> > Python-ast.h/c
> >
> > Two questions:
> >
> > * Should I always check-in Python-ast.h and Python-ast.c when I
> > touch asdl* ? The generated files are unchanged, it's only the
> > timestamp that changed.
> > * Can we, in theory, use new Pythons for asdl* code, because
> > Python-ast.* are, in fact, checked in so they don't have to be
> > rebuilt by the bots or users?
> 
> We should have the buildbots run "make touch", so they don't need to
> run asdl_c.py.

So, you're gonna like this:

hg --config extensions.touch=Tools/hg/hgtouch.py touch -v
Tools/hg/hgtouch.py:21: Warning: 'with' will become a reserved keyword in 
Python 2.6
*** failed to import extension touch from Tools/hg/hgtouch.py: invalid syntax 
(hgtouch.py, line 21)
hg: unknown command 'touch'

http://buildbot.python.org/all/buildslaves/bolen-ubuntu

(that buildbot runs Ubuntu 8.04 LTS, for the record)

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asdl.py and Python-ast.[hc]

2013-09-27 Thread Eli Bendersky 
On Fri, Sep 27, 2013 at 5:09 AM, Antoine Pitrou  wrote:

> Le Thu, 26 Sep 2013 10:28:46 -0400,
> Benjamin Peterson  a écrit :
> > 2013/9/26 Eli Bendersky :
> > > Hi All,
> > >
> > > Earlier this morning I had a slight tackle with a couple of the 3.4
> > > bots (sorry everyone!). I fixed some problems in asdl.py -
> > > http://hg.python.org/cpython/rev/21d46e3ae60c - and used the 'with'
> > > statement. Some bots don't have Python 2.6+ and couldn't bootstrap
> > > Python-ast.h/c
> > >
> > > Two questions:
> > >
> > > * Should I always check-in Python-ast.h and Python-ast.c when I
> > > touch asdl* ? The generated files are unchanged, it's only the
> > > timestamp that changed.
> > > * Can we, in theory, use new Pythons for asdl* code, because
> > > Python-ast.* are, in fact, checked in so they don't have to be
> > > rebuilt by the bots or users?
> >
> > We should have the buildbots run "make touch", so they don't need to
> > run asdl_c.py.
>
> So, you're gonna like this:
>
> hg --config extensions.touch=Tools/hg/hgtouch.py touch -v
> Tools/hg/hgtouch.py:21: Warning: 'with' will become a reserved keyword in
> Python 2.6
> *** failed to import extension touch from Tools/hg/hgtouch.py: invalid
> syntax (hgtouch.py, line 21)
> hg: unknown command 'touch'
>
> http://buildbot.python.org/all/buildslaves/bolen-ubuntu
>
> (that buildbot runs Ubuntu 8.04 LTS, for the record)
>

We have to define a clear boundary between what needs to be compatible to
old Pythons and what doesn't. As far as auto-generated files are concerned,
once we set up the bots properly and fix the .hgtouch bugs, there's no
reason for anyone to need an old Python for anything except the hgtouch
extension itself. But the latter has to be back-ported to work on older
Pythons (I suppose from 2.4, or is there reason to go earlier?)

FWIW Antoine, I'll be happy to help with the buildbot setup, but you'll
have to tell me how to get access to our buildbot scripts :-)

Eli
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Stephen J. Turnbull 
Nick Coghlan writes:

 > I'm not sure what usage model you're assuming for _ensurepip, but it
 > appears to be wrong. End users should be able to just run pip, and
 > either have it work, or else get a message from the OS vendor telling
 > them to install the appropriate system package.

I don't understand how you arrange for that message on existing
installs.  Wouldn't it be easier to just lobby the distros to make
Python dependent on pip?  And speaking of vendors, do you expect Apple
and Microsoft to provide such a message?  And such a system package?

If you already are running a Linux distro or MacPorts, you do "apt-get
python-pip" and "port install py-pip" respectively.  I bet Cygwin is
the same with yet another spelling.  Where's the problem?  You say:

 > New users on Windows and Mac OS X. I've heard many more complaints
 > from folks running tutorials about the pip bootstrapping process than
 > I ever have from the community at large about the GIL :P

I bet those users are *not* running third-party distros, but rather
are sitting in front of pretty close to plain vanilla factory installs
of the OS, no?  And "new users" on Mac OS X already have "old installs" 
of Python, no?

That's my model.  In that model I don't see backporting PEP 453 to
Python 2.7 as being a sufficiently reliable way to provide a smooth
user experience to justify breaking the "no new features" rule (which
is at the "read my lips" level after the True/False fiasco).

Get a commitment from Apple to put 2.7.6 in their next upgrades for
their OS, and then maybe you'd have enough leverage to tip the
balance.  I certainly would concede the point.  But without that,
you're telling Mac users "you have to upgrade Python from a 3rd party
site."  Is that really the way to make new users participating in a
tutorial session happy?  (You tell me, I'm just introspecting here.)

Steve
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Paul Moore 
On 27 September 2013 15:08, Stephen J. Turnbull  wrote:
>> New users on Windows and Mac OS X. I've heard many more complaints
>  > from folks running tutorials about the pip bootstrapping process than
>  > I ever have from the community at large about the GIL :P
>
> I bet those users are *not* running third-party distros, but rather
> are sitting in front of pretty close to plain vanilla factory installs
> of the OS, no?  And "new users" on Mac OS X already have "old installs"
> of Python, no?

Windows users who don't use a third-party distro like Enthought,
generally download the python.org installer. At the moment, that
doesn't give them a "pip" command. So if they want to install any
third party package, they have to start by installing pip. The
instructions for that are reasonably clear, but non-trivial, largely
because tools like curl are not commonly available on Windows, and by
default running a Python script may not do what you expect.

Rather than try to fix these problems (which are *hard*) the intent is
to have the pip command installed by the python.org installer.

So, for Windows users, installing a package becomes "pip install XXX".

The problem is that this doesn't work for existing releases (2.7 and
3.3). Rather than have a convoluted set of instructions that goes "if
you're not on Python 3.4+, (basically do what we have at the moment)"
the PEP makes it possible to say "If you have a Python older than 3.4,
upgrade to the latest maintenance release of your version of Python,
then use pip". People who have reasons not to use the latest
*maintenance* release are assumed to be special cases who can either
deal with the more complex current process, or can work something out
for themselves. (They may not be, but there's not much we can do in
practice to help them).

Nobody in the basic target group should be running ensurepip (under
any name) manually.

I can't speak for Linux distros or OSX users, but for Windows I do
believe that this is a significant improvement, and worth the (IMO,
negligible) risk involved in adding this to a maintenance release.
There *may* be some mileage in a debate about why we don't just bundle
pip in the installer, rather than having helpers in core Python
itself, but the long & short of it is that ensurepip is needed for
3.4+ to make installing pip in venvs work by default, and why have a
completely different and so less well tested mechanism for older
versions?

Paul.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asdl.py and Python-ast.[hc]

2013-09-27 Thread Martin v. Löwis 
Am 26.09.13 15:52, schrieb Eli Bendersky:
> * Should I always check-in Python-ast.h and Python-ast.c when I touch
> asdl* ? The generated files are unchanged, it's only the timestamp that
> changed.

If they really didn't change, I don't think it matters much. I believe
there is a fundamental problem in Mercurial which fails to get it
"right" - with the defense that one shouldn't check in generated files
in the first place.

"hg touch" is supposed to work around this limitation. So when you only
check in the generator, anybody updating should do "make touch" after
the update, which should touch the generated files even though they
didn't change.

> * Can we, in theory, use new Pythons for asdl* code, because
> Python-ast.* are, in fact, checked in so they don't have to be rebuilt
> by the bots or users?

I'd say yes. That's the point of checking in generated files, so that
users don't need to run the generator.

> While we're at it, it seems that .hgtouch is wrong:
>
> Include/ast.h: Parser/Python.asdl Parser/asdl.py Parser/asdl_c.py
> Python/Python-ast.c: Include/ast.h
>
> The file Include/ast.h is not,

It may well be incorrect - feel free to fix it.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asdl.py and Python-ast.[hc]

2013-09-27 Thread Martin v. Löwis 
Am 26.09.13 23:00, schrieb Antoine Pitrou:

> Here you are:
> http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/28/steps/compile/logs/stdio
> 
> Of course, when it's using "-jN" there may be a race condition :-)

Could you make "make touch" a separate build step?

Regards,
Martin
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Mark Lawrence 

On 27/09/2013 15:26, Paul Moore wrote:


So, for Windows users, installing a package becomes "pip install XXX".



Apologies if this has already been said but it only works if you've 
already installed an appropriate compiler.  I've lost count of the 
number of times I've tried this, got the (rather cyptic) "error: Unable 
to find vcvarsall.bat" message and then gone off to find a suitable 
binary download.


--
Cheers.

Mark Lawrence

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Donald Stufft 

On Sep 27, 2013, at 10:39 AM, Mark Lawrence  wrote:

> Apologies if this has already been said but it only works if you've already 
> installed an appropriate compiler.  I've lost count of the number of times 
> I've tried this, got the (rather cyptic) "error: Unable to find 
> vcvarsall.bat" message and then gone off to find a suitable binary download.

Going forward Wheels are binary packages that pip can install.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asdl.py and Python-ast.[hc]

2013-09-27 Thread Antoine Pitrou 
Le Fri, 27 Sep 2013 16:34:41 +0200,
"Martin v. Löwis"  a écrit :
> Am 26.09.13 23:00, schrieb Antoine Pitrou:
> 
> > Here you are:
> > http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/28/steps/compile/logs/stdio
> > 
> > Of course, when it's using "-jN" there may be a race condition :-)
> 
> Could you make "make touch" a separate build step?

I'm not sure it fits in buildbot's standard "GNUAutoconf" build factory:
http://docs.buildbot.net/current/manual/cfg-buildfactories.html#index-1

Note that "compile" is a "shell command" so perhaps it is actually
possible to pass "make touch && make -jN". Otherwise, another build
factory will have to be used.

I'll give an access to Eli so that he can try to figure it out :-)

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Paul Moore 
On 27 September 2013 15:39, Mark Lawrence  wrote:
> On 27/09/2013 15:26, Paul Moore wrote:
>
>> So, for Windows users, installing a package becomes "pip install XXX".
>>
>
> Apologies if this has already been said but it only works if you've already
> installed an appropriate compiler.  I've lost count of the number of times
> I've tried this, got the (rather cyptic) "error: Unable to find
> vcvarsall.bat" message and then gone off to find a suitable binary download.

I was assuming that you had whatever's necessary to install - a
compiler, any necessary libraries, whatever. Or more plausibly, as
Donald pointed out, a wheel.

But yes, you're right, this doesn't solve the problem of *building*
distributions. It's not intended to (except by enabling communities to
start distributing wheels as a pain-free binary solution). Whether
that's an issue depends on the community (AIUI, it's a major hassle
for scientific users, not so much for web developers, for example)

Paul
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asdl.py and Python-ast.[hc]

2013-09-27 Thread Eli Bendersky 
On Fri, Sep 27, 2013 at 7:26 AM, "Martin v. Löwis" wrote:

> Am 26.09.13 15:52, schrieb Eli Bendersky:
> > * Should I always check-in Python-ast.h and Python-ast.c when I touch
> > asdl* ? The generated files are unchanged, it's only the timestamp that
> > changed.
>
> If they really didn't change, I don't think it matters much. I believe
> there is a fundamental problem in Mercurial which fails to get it
> "right" - with the defense that one shouldn't check in generated files
> in the first place.
>
> "hg touch" is supposed to work around this limitation. So when you only
> check in the generator, anybody updating should do "make touch" after
> the update, which should touch the generated files even though they
> didn't change.
>
> > * Can we, in theory, use new Pythons for asdl* code, because
> > Python-ast.* are, in fact, checked in so they don't have to be rebuilt
> > by the bots or users?
>
> I'd say yes. That's the point of checking in generated files, so that
> users don't need to run the generator.
>

Thank you for the explanation, Martin.


>
> > While we're at it, it seems that .hgtouch is wrong:
> >
> > Include/ast.h: Parser/Python.asdl Parser/asdl.py Parser/asdl_c.py
> > Python/Python-ast.c: Include/ast.h
> >
> > The file Include/ast.h is not,
>
> It may well be incorrect - feel free to fix it.
>

Thanks. There are a couple of things to address before we can try to
actually run 'make touch' on all bots. I opened
http://bugs.python.org/issue19106 to track this.

Eli
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Official github mirror for CPython?

2013-09-27 Thread Eli Bendersky 
On Thu, Jul 25, 2013 at 7:48 AM, Brian Curtin  wrote:

> On Thu, Jul 25, 2013 at 9:37 AM, Christian Heimes 
> wrote:
> > Am 25.07.2013 16:29, schrieb Eli Bendersky:
> >> Hi all,
> >>
> >> I've been looking for a Github mirror for Python, and found two:
> >>
> >> * https://github.com/python-git/python has a lot of
> forks/watches/starts
> >> but seems to be very out of date (last updated 4 years ago)
> >> * https://github.com/python-mirror/python doesn't appear to be very
> >> popular but is updated daily
> >>
> >> Are some of you the owners of these repositories? Should we consolidate
> >> to a single "semi-official" mirror?
> >
> > +1
> >
> > Does the PSF have an official account on github? We have one on
> bitbucket...
>
> I don't remember who runs this, and I thought I was in it (maybe just
> on BB), but: https://github.com/python
>

The list of members for https://github.com/python is
https://github.com/python?tab=members

How can I get added to that list? When that happens, I can try to set-up a
regularly updated CPython mirror.

Eli
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

2013-09-27 Thread Python tracker 

ACTIVITY SUMMARY (2013-09-20 - 2013-09-27)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open4256 (+28)
  closed 26624 (+22)
  total  30880 (+50)

Open issues with patches: 1963 


Issues opened (44)
==

#19058: test_sys.test_ioencoding_nonascii() fails with ASCII locale en
http://bugs.python.org/issue19058  opened by pitrou

#19060: docs: note that subprocess doesn't replace os.exec*
http://bugs.python.org/issue19060  opened by techtonik

#19062: problems with pyshell to get userdir
http://bugs.python.org/issue19062  opened by weizhao

#19063: Python 3.3.3  encodes emails containing non-ascii data as 7bit
http://bugs.python.org/issue19063  opened by apollo13

#19065: sqlite3 timestamp adapter chokes on timezones
http://bugs.python.org/issue19065  opened by acdha

#19066: os.execv fails with spaced names on  Windows
http://bugs.python.org/issue19066  opened by techtonik

#19067: Built-in range docstrings are not PEP-8 compatible
http://bugs.python.org/issue19067  opened by marco.buttu

#19068: Some built-in complex docstrings are not PEP-8 compatible
http://bugs.python.org/issue19068  opened by marco.buttu

#19069: Built-in float docstrings are not PEP-8 compatible
http://bugs.python.org/issue19069  opened by marco.buttu

#19070: In place operators of weakref.proxy() not returning self.
http://bugs.python.org/issue19070  opened by grahamd

#19071: Documentation on what self is for module-level functions is mi
http://bugs.python.org/issue19071  opened by grahamd

#19072: classmethod doesn't honour descriptor protocol of wrapped call
http://bugs.python.org/issue19072  opened by grahamd

#19073: Inability to specific __qualname__ as a property on a class in
http://bugs.python.org/issue19073  opened by grahamd

#19074: Add PySide to GUI FAQ
http://bugs.python.org/issue19074  opened by techtonik

#19075: Add sorting algorithm visualization to turtledemo
http://bugs.python.org/issue19075  opened by Jason.Yeo

#19076: Pdb.do_break calls error with obsolete file kwarg
http://bugs.python.org/issue19076  opened by Michael.Smith

#19077: More robust TemporaryDirectory cleanup
http://bugs.python.org/issue19077  opened by serhiy.storchaka

#19078: Allow reversed(memoryview), like memoryview
http://bugs.python.org/issue19078  opened by Claudiu.Popa

#19079: chameleon benchmark fails on 3.4
http://bugs.python.org/issue19079  opened by pitrou

#19080: Enrich SyntaxError with additional information
http://bugs.python.org/issue19080  opened by alonho

#19081: zipimport behaves badly when the zip file changes while the pr
http://bugs.python.org/issue19081  opened by gregory.p.smith

#19082: Lib/xmlrpc/client.py demo code points to the dead server
http://bugs.python.org/issue19082  opened by vajrasky

#19083: IDNA prefix should be case insensitive
http://bugs.python.org/issue19083  opened by Pepijn.de.Vos

#19084: No way to use TLS-PSK from python ssl
http://bugs.python.org/issue19084  opened by karlp

#19085: Add tkinter basic options tests
http://bugs.python.org/issue19085  opened by serhiy.storchaka

#19086: Make fsum usable incrementally.
http://bugs.python.org/issue19086  opened by oscarbenjamin

#19087: bytearray front-slicing not optimized
http://bugs.python.org/issue19087  opened by pitrou

#19088: TypeError with pickle in embedded python3.3 when starting mult
http://bugs.python.org/issue19088  opened by Larry.Pete

#19089: Windows: Make Ctrl-D exit key combination cross-platform
http://bugs.python.org/issue19089  opened by techtonik

#19091: ast.parse gives wrong position for some Names when non-ascii c
http://bugs.python.org/issue19091  opened by Aivar.Annamaa

#19092: ExitStack.__exit__ incorrectly suppresses exceptions in __exit
http://bugs.python.org/issue19092  opened by hniksic

#19094: urljoin should raise a TypeError if URL is not a string
http://bugs.python.org/issue19094  opened by jason.coombs

#19095: Document SSLSocket.getpeercert always returns None without do_
http://bugs.python.org/issue19095  opened by dsuch

#19096: multiprocessing.Pool._terminate_pool restarts workers during s
http://bugs.python.org/issue19096  opened by ecatmur

#19097: bool(cgi.FieldStorage(...)) may be False unexpectedly
http://bugs.python.org/issue19097  opened by gvanrossum

#19099: struct.pack fails first time with unicode fmt
http://bugs.python.org/issue19099  opened by miwa

#19100: Use backslashreplace in pprint
http://bugs.python.org/issue19100  opened by serhiy.storchaka

#19102: Add tests for CLI of the tabnanny module
http://bugs.python.org/issue19102  opened by berker.peksag

#19103: Use pprint in displayhook
http://bugs.python.org/issue19103  opened by serhiy.storchaka

#19104: pprint produces invalid output for long strings
http://bugs.python.org/issue19104  opened by serhiy.storchaka

#19105: pprint doesn't use all width
http://bugs.python.org/issue19105  opened by

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread R. David Murray 
On Fri, 27 Sep 2013 15:26:41 +0100, Paul Moore  wrote:
> On 27 September 2013 15:08, Stephen J. Turnbull  wrote:
> >> New users on Windows and Mac OS X. I've heard many more complaints
> >  > from folks running tutorials about the pip bootstrapping process than
> >  > I ever have from the community at large about the GIL :P
> >
> > I bet those users are *not* running third-party distros, but rather
> > are sitting in front of pretty close to plain vanilla factory installs
> > of the OS, no?  And "new users" on Mac OS X already have "old installs"
> > of Python, no?
> 
> Windows users who don't use a third-party distro like Enthought,
> generally download the python.org installer. At the moment, that
> doesn't give them a "pip" command. So if they want to install any
> third party package, they have to start by installing pip. The
> instructions for that are reasonably clear, but non-trivial, largely
> because tools like curl are not commonly available on Windows, and by
> default running a Python script may not do what you expect.
> 
> Rather than try to fix these problems (which are *hard*) the intent is
> to have the pip command installed by the python.org installer.
[...]
> I can't speak for Linux distros or OSX users, but for Windows I do
> believe that this is a significant improvement, and worth the (IMO,
> negligible) risk involved in adding this to a maintenance release.

I'm not an OS X user, and probably most people on this list use macports
or something similar, which essentially puts them in the same boat as
the linux users...and there's a section in the PEP about that (that's
where the message about installing pip if you run pip and the distro
didn't include it with python is supposed to come from).

For OS X users *not* using something like macports, I'm pretty sure they
are going to be in a similar boat to the Windows users, with just a touch
of added confusion coming from the fact that an older version of Python
is already installed.  But the instructions they will find on the web
for installing package X (once this change hits the field) will be to
install the newest version of 2.7 (or 3) using the python.org installer,
and then they will have the pip command and can go from there.

--David
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Daniel Holth 
On Fri, Sep 27, 2013 at 12:15 PM, R. David Murray  wrote:
> On Fri, 27 Sep 2013 15:26:41 +0100, Paul Moore  wrote:
>> On 27 September 2013 15:08, Stephen J. Turnbull  wrote:
>> >> New users on Windows and Mac OS X. I've heard many more complaints
>> >  > from folks running tutorials about the pip bootstrapping process than
>> >  > I ever have from the community at large about the GIL :P
>> >
>> > I bet those users are *not* running third-party distros, but rather
>> > are sitting in front of pretty close to plain vanilla factory installs
>> > of the OS, no?  And "new users" on Mac OS X already have "old installs"
>> > of Python, no?
>>
>> Windows users who don't use a third-party distro like Enthought,
>> generally download the python.org installer. At the moment, that
>> doesn't give them a "pip" command. So if they want to install any
>> third party package, they have to start by installing pip. The
>> instructions for that are reasonably clear, but non-trivial, largely
>> because tools like curl are not commonly available on Windows, and by
>> default running a Python script may not do what you expect.
>>
>> Rather than try to fix these problems (which are *hard*) the intent is
>> to have the pip command installed by the python.org installer.
> [...]
>> I can't speak for Linux distros or OSX users, but for Windows I do
>> believe that this is a significant improvement, and worth the (IMO,
>> negligible) risk involved in adding this to a maintenance release.
>
> I'm not an OS X user, and probably most people on this list use macports
> or something similar, which essentially puts them in the same boat as
> the linux users...and there's a section in the PEP about that (that's
> where the message about installing pip if you run pip and the distro
> didn't include it with python is supposed to come from).
>
> For OS X users *not* using something like macports, I'm pretty sure they
> are going to be in a similar boat to the Windows users, with just a touch
> of added confusion coming from the fact that an older version of Python
> is already installed.  But the instructions they will find on the web
> for installing package X (once this change hits the field) will be to
> install the newest version of 2.7 (or 3) using the python.org installer,
> and then they will have the pip command and can go from there.
>
> --David

OS X and Linux change Python in ways that can be confusing to new and
experienced users, like not installing the stdlib source code by
default, or not installing the profiler, or simply by being out of
date. On these platforms attempting to use the system Python for
development can be a costly mistake instead of a convenience.

Users get a more consistent experience by starting with the installers
from python.org. Hopefully the tutorials will reflect the consistency
added by this PEP.

This PEP only gets pip, an operation which is a recurring
inconvenience for me even though I use Linux. It does not solve any of
the problems you may have after pip has been installed.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Stephen J. Turnbull 
Paul Moore writes:

 > I can't speak for Linux distros or OSX users, but for Windows I do
 > believe that this is a significant improvement,

Nobody doubts this.

 > and worth the (IMO, negligible) risk involved in adding this to a
 > maintenance release.

Doesn't that argument apply equally well to any new feature?  The
proponents of such changes always characterize them as "worth the
(IMO, negligible) risk involved".  I am sure that the proponents of
any such feature are equally sincere about that!

Also, I think that proponents of backporting this PEP are missing
something important.  Specifically, why are we encouraging the use of
Python 2.7 for "new users"?  Shouldn't we use this as an opportunity
to say, "Move to Python 3.4 and forget the 'agony of installing pip'
issue forever?"



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Raymond Hettinger 

On Sep 23, 2013, at 7:15 AM, Nick Coghlan  wrote:

> With the last round of updates, I believe PEP 453 is ready for
> Martin's pronouncement.

Personally, I'm very excited and happy that this or something like it
is coming close to fruition.  

My experiences in userland suggest that this will be a big step
forward for Python usability.


Raymond

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Donald Stufft 

On Sep 27, 2013, at 2:14 PM, "Stephen J. Turnbull"  wrote:

> Also, I think that proponents of backporting this PEP are missing
> something important.  Specifically, why are we encouraging the use of
> Python 2.7 for "new users"?  Shouldn't we use this as an opportunity
> to say, "Move to Python 3.4 and forget the 'agony of installing pip'
> issue forever?"

Because reality is that new users are still likely to be using Python 2.7. 
Python 3
is just now starting to be really usable, however there's a huge corpus of 
existing
tutorials, course work, books etc for Python 2.7. As Python 3 becomes more 
usable
that existing corpus of material will be ported over to Python 3 but in the 
interim
there is still a pretty large hurdle for new users to get over.

That's assuming that they are even able to use Python 3 and whatever they are 
trying
to do with all of their libraries are ported to Python3. I still think Python 
2.7 is a better
target for new users because if you're using Python 3.x theirs a high chance 
you'll
need to port a library or two still.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Guido van Rossum 
On Fri, Sep 27, 2013 at 11:22 AM, Donald Stufft  wrote:

>
> On Sep 27, 2013, at 2:14 PM, "Stephen J. Turnbull" 
> wrote:
>
> > Also, I think that proponents of backporting this PEP are missing
> > something important.  Specifically, why are we encouraging the use of
> > Python 2.7 for "new users"?  Shouldn't we use this as an opportunity
> > to say, "Move to Python 3.4 and forget the 'agony of installing pip'
> > issue forever?"
>
> Because reality is that new users are still likely to be using Python 2.7.
> Python 3
> is just now starting to be really usable, however there's a huge corpus of
> existing
> tutorials, course work, books etc for Python 2.7. As Python 3 becomes more
> usable
> that existing corpus of material will be ported over to Python 3 but in
> the interim
> there is still a pretty large hurdle for new users to get over.
>
> That's assuming that they are even able to use Python 3 and whatever they
> are trying
> to do with all of their libraries are ported to Python3. I still think
> Python 2.7 is a better
> target for new users because if you're using Python 3.x theirs a high
> chance you'll
> need to port a library or two still.
>

Based on my day-to-day experience this is still very true. (And yes, I'm
slowly turning the tide. But it will take a long time and I am committed to
giving users the choice.)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Terry Reedy 

On 9/27/2013 10:26 AM, Paul Moore wrote:
[snip longish post]
I want to summarize the main points of what I believe Paul said and 
strongly agree with them.


* For this issue, and especially for backporting to 2.7/3.3, we should 
consider Windows, Mac, and *nix distributions as separate cases.


* For Windows users, it would be really good if the PSF installer for 
the next releases of all versions at least optionally resulted in the 
installation of the most recent pip possible.


I add: just how that is accomplished is not the users concern, except 
possibly for using the net to check for a later version of pip. Also, we 
can encourage but not command Enthought and ActiveState to do the same 
suite in their plus distributions.


* For 2.7/3.3, Windows users have no need to run _ensurepip after 
installation.


I add: for 2.7/3.3, there is consequently no need for _ensurepip to be 
in /Lib after installation, even if temporarily added*. If it is not 
there, there is no change the the stdlib, and hence no violation of the 
'no new features' policy. The optional installation of pip is not a 
change to Python itself.


* Where the 2.7/3.3 installers merely bundle pip or use the 3.4 
procedure with an extra delete step strikes me as an implementation 
detail best decided by the installer maker (Martin).


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Donald Stufft 

On Sep 27, 2013, at 2:50 PM, Terry Reedy  wrote:

> I add: for 2.7/3.3, there is consequently no need for _ensurepip to be in 
> /Lib after installation, even if temporarily added*. If it is not there, 
> there is no change the the stdlib, and hence no violation of the 'no new 
> features' policy. The optional installation of pip is not a change to Python 
> itself.

This sounds like a really bad idea to me. You're going to end up with a 
different stdlib not only by minor release, but by if they installed through an 
installer or not.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Terry Reedy 

On 9/27/2013 3:10 PM, Donald Stufft wrote:


On Sep 27, 2013, at 2:50 PM, Terry Reedy  wrote:


I add: for 2.7/3.3, there is consequently no need for _ensurepip to be in /Lib 
after installation, even if temporarily added*. If it is not there, there is no 
change the the stdlib, and hence no violation of the 'no new features' policy. 
The optional installation of pip is not a change to Python itself.


This sounds like a really bad idea to me.


Why would you think that an idea aimed at ending an argument blocking 
your proposal is bad. This seems like a really bad response to me.



You're going to end up with a different stdlib not only by minor release, but 
by if they installed through an installer or not.


The current proposal is to add a new module to the stdlib in a bugfix 
release, which looks like a violation of current policy. We agree that 
that end result of pip installed would be good. We are arguing over 
whether adding '_' to the name makes it not a violation or whether the 
good outweighs the bad of a violation. I claim that the arguement is not 
necessary and can be ended by not making the addition or by hiding it.


I presume your objection refers to the fact that one can clone the 
repository and compile Python on Windows, albeit with some difficulty. 
My three responses:


1. I do not consider the the result to be 'installed Python', at least 
not as I have used the project file.


2. The ratio of people building Python on Windows to those downloading 
and running an installer is so close to 0 that it can be ignored. People 
who build Python on Windows are not typical Python beginners.


3. If you do not agree with 1 and 2 and object to _ensurepip being in 
/Lib in such limited circumstances, then either put it in /Tools/scripts 
or do not use it at all. I already said that the 2.7/3.3 Windows 
installer maker (Martin) should decide whether to even use it.


4. The argument for including _ensurepip somewhere in the repository it 
that people who *do* build python.exe could then use it to install pip 
the first time. /Tools/scripts would be sufficient for this.


5. The result of not having /Lib/_ensurepip in installed Python would, 
in any case, be a lessor violation of the policy.


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Donald Stufft 

On Sep 27, 2013, at 4:09 PM, Terry Reedy  wrote:

> On 9/27/2013 3:10 PM, Donald Stufft wrote:
>> 
>> On Sep 27, 2013, at 2:50 PM, Terry Reedy  wrote:
>> 
>>> I add: for 2.7/3.3, there is consequently no need for _ensurepip to be in 
>>> /Lib after installation, even if temporarily added*. If it is not there, 
>>> there is no change the the stdlib, and hence no violation of the 'no new 
>>> features' policy. The optional installation of pip is not a change to 
>>> Python itself.
>> 
>> This sounds like a really bad idea to me.
> 
> Why would you think that an idea aimed at ending an argument blocking your 
> proposal is bad. This seems like a really bad response to me.

Because I think it's a fundamentally bad idea.

> 
>> You're going to end up with a different stdlib not only by minor release, 
>> but by if they installed through an installer or not.
> 
> The current proposal is to add a new module to the stdlib in a bugfix 
> release, which looks like a violation of current policy. We agree that that 
> end result of pip installed would be good. We are arguing over whether adding 
> '_' to the name makes it not a violation or whether the good outweighs the 
> bad of a violation. I claim that the arguement is not necessary and can be 
> ended by not making the addition or by hiding it.
> 
> I presume your objection refers to the fact that one can clone the repository 
> and compile Python on Windows, albeit with some difficulty. My three 
> responses:
> 
> 1. I do not consider the the result to be 'installed Python', at least not as 
> I have used the project file.
> 
> 2. The ratio of people building Python on Windows to those downloading and 
> running an installer is so close to 0 that it can be ignored. People who 
> build Python on Windows are not typical Python beginners.
> 
> 3. If you do not agree with 1 and 2 and object to _ensurepip being in /Lib in 
> such limited circumstances, then either put it in /Tools/scripts or do not 
> use it at all. I already said that the 2.7/3.3 Windows installer maker 
> (Martin) should decide whether to even use it.
> 
> 4. The argument for including _ensurepip somewhere in the repository it that 
> people who *do* build python.exe could then use it to install pip the first 
> time. /Tools/scripts would be sufficient for this.
> 
> 5. The result of not having /Lib/_ensurepip in installed Python would, in any 
> case, be a lessor violation of the policy.

If it lives in the source tree how are you going to provent it from existing 
when someone installs on Linux? OSX? One of the BSDs? It seems to me your 
proposal is to add the _ensurepip module… except when they install it via 
Windows installer. 

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Zachary Ware 
On Fri, Sep 27, 2013 at 3:29 PM, Donald Stufft  wrote:
>

>
> If it lives in the source tree how are you going to provent it from existing 
> when someone installs on Linux? OSX? One of the BSDs?

If someone is building their own Python from source--regardless of
platform--they're obviously going to have _ensurepip available one way
or another, and such users will need to have it available to match the
capabilities of the installer (or create their own).  But if you're
building your own Python, you should already know enough about what's
going on to know when and whether _ensurepip should be used and how.
On the other hand, when you use an installer (be it Windows, OSX, or
otherwise), you really only need _ensurepip one time, ever: at install
time.  Even then, you don't actually need to know anything about
_ensurepip at all, just whether to check the box or not.  If you
decide you need it later, you can always re-install.

> It seems to me your [Terry's] proposal is to add the _ensurepip module… 
> except when they install it via Windows installer.

The way I read Terry's proposal, it is to never add the _ensurepip
*module*, but to use (or make available, whichever makes sense in a
given case) the _ensurepip *script* when it is requested at
install-time: specifically, put _ensurepip.py in Tools/scripts, PC/,
Mac/, or really anywhere but Lib/ so that builders can find it, but
Python can't.  In other words, don't make "import _ensurepip" possible
out of the box, and a lot of the "don't add new features in
maintenance releases" blockade disappears, because you aren't actually
adding any new capability to Python itself or its standard library.

Of course, this proposal only applies to 2.7/3.3.  Since _ensurepip
will be used for venv as well as initial install in 3.4, it should be
a full-blown stdlib module in that version, probably even without the
leading underscore.

-- 
Zach
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Official github mirror for CPython?

2013-09-27 Thread Jesse Noller 
Email me the name of the repo you want, and your github username
(preferably off list so I don't miss it!) and I will set you up Eli

On Fri, Sep 27, 2013 at 11:02 AM, Eli Bendersky  wrote:
>
>
>
> On Thu, Jul 25, 2013 at 7:48 AM, Brian Curtin  wrote:
>>
>> On Thu, Jul 25, 2013 at 9:37 AM, Christian Heimes 
>> wrote:
>> > Am 25.07.2013 16:29, schrieb Eli Bendersky:
>> >> Hi all,
>> >>
>> >> I've been looking for a Github mirror for Python, and found two:
>> >>
>> >> * https://github.com/python-git/python has a lot of
>> >> forks/watches/starts
>> >> but seems to be very out of date (last updated 4 years ago)
>> >> * https://github.com/python-mirror/python doesn't appear to be very
>> >> popular but is updated daily
>> >>
>> >> Are some of you the owners of these repositories? Should we consolidate
>> >> to a single "semi-official" mirror?
>> >
>> > +1
>> >
>> > Does the PSF have an official account on github? We have one on
>> > bitbucket...
>>
>> I don't remember who runs this, and I thought I was in it (maybe just
>> on BB), but: https://github.com/python
>
>
> The list of members for https://github.com/python is
> https://github.com/python?tab=members
>
> How can I get added to that list? When that happens, I can try to set-up a
> regularly updated CPython mirror.
>
> Eli
>
>
>
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio

2013-09-27 Thread Guido van Rossum 
I've been looking at my progress with Tulip and the 3.4 release schedule
(PEP 429) and it looks like I will have to do some kind of sprint to get it
into the release in time for beta 1, which is planned for Nov 24. Ideally
I'd get it into alpha 4, which is scheduled for Oct 20 -- that's in about
three weeks, and probably too tight.

Even Nov 24 is aggressive, because the PEP (PEP 3156) hasn't even been
discussed formally, let alone accepted! Fortunately I'm pretty happy with
most of the APIs defined in the PEP -- there are some holes but I expect no
big changes at this point.

It's clear that the only way we can get this into the stdlib is to mark it
as provisional, per PEP 411. That's fine with me. I expect that the kind of
changes the code will see between the 3.4 and 3.5 releases are well within
the bounds of the expectations set by that PEP -- while it is clear that
everything is possible (even withdrawal), the most likely outcome is that
the API will be extended or tweaked at most, and not significantly changed
in a backward compatible way -- without completely ruling out that some
part of the API may deserve a serious overhaul based on experience. That's
exactly how I feel about Tulip.

I propose that the new library will be named asyncio. It would be odd if we
kept the name tulip (stdlib modules rarely have "creative" names), and
"asynchronous I/O" seems to cover the contents quite well.

I propose that we do the bikeshedding about the API on the
[email protected] mailing list; I'm not sure what we would gain
by holding the discussion on python-dev (although clearly we should report
back here with important milestones in the review). I will post a message
with the kick-off there.

I hope people will respect my choice of venue, and limit themselves to
procedural issued on python-dev. E.g. it's fine to debate on python-dev
whether I'm overstepping my BDFL authority here, or whether the proposed
API is of sufficiently wide appeal. But I'd prefer to discuss e.g. the
return type of start_serving() or the choice of yield-from over yield on
python-tulip.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Barry Warsaw 
On Sep 26, 2013, at 02:30 PM, Nick Coghlan wrote:

>- the module name should be "_ensurepip" in all versions
>- the PEP should explicitly state that the "don't remove _ensurepip
>and it's wheel files" caveat for redistributors applies only in 3.4+
>(where removing it will break pyvenv)

I'm sorry that I probably won't be able to engage more on this thread, but I
think my points should be fairly well understood by the PEP czar and RM.
Should the PEP be accepted, I think both of these are good changes.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Nick Coghlan 
On 28 Sep 2013 00:08, "Stephen J. Turnbull"  wrote:
>
> Nick Coghlan writes:
>
>  > I'm not sure what usage model you're assuming for _ensurepip, but it
>  > appears to be wrong. End users should be able to just run pip, and
>  > either have it work, or else get a message from the OS vendor telling
>  > them to install the appropriate system package.
>
> I don't understand how you arrange for that message on existing
> installs.  Wouldn't it be easier to just lobby the distros to make
> Python dependent on pip?

Most distros of interest already emit that message - it's part of a
standard mechanism to check for system packages if a command isn't found
(and I believe even RHEL and derivatives may support this for pip if the
EPEL repo is enabled).

> And speaking of vendors, do you expect Apple
> and Microsoft to provide such a message?  And such a system package?

No, that's why the proposal is to modify the CPython installers for those
platforms.

>
> If you already are running a Linux distro or MacPorts, you do "apt-get
> python-pip" and "port install py-pip" respectively.  I bet Cygwin is
> the same with yet another spelling.  Where's the problem?  You say:
>
>  > New users on Windows and Mac OS X. I've heard many more complaints
>  > from folks running tutorials about the pip bootstrapping process than
>  > I ever have from the community at large about the GIL :P
>
> I bet those users are *not* running third-party distros, but rather
> are sitting in front of pretty close to plain vanilla factory installs
> of the OS, no?  And "new users" on Mac OS X already have "old installs"
> of Python, no?

No. Instuctors tell users on Mac OS X to install from python.org or use one
of the third party package managers.

>
> That's my model.  In that model I don't see backporting PEP 453 to
> Python 2.7 as being a sufficiently reliable way to provide a smooth
> user experience to justify breaking the "no new features" rule (which
> is at the "read my lips" level after the True/False fiasco).

You have confirmed my belief that your model is incorrect. The feedback I
have received is that the majority of beginners are introduced to Python by
downloading the binary installers from python.org for Windows or Mac OS X.

> Get a commitment from Apple to put 2.7.6 in their next upgrades for
> their OS, and then maybe you'd have enough leverage to tip the
> balance.  I certainly would concede the point.  But without that,
> you're telling Mac users "you have to upgrade Python from a 3rd party
> site."  Is that really the way to make new users participating in a
> tutorial session happy?  (You tell me, I'm just introspecting here.)

Yes, that's exactly what happens. People don't use the system Python on Mac
OS X the way they do on *nix systems.

Cheers,
Nick.

>
> Steve
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Benjamin Peterson 
2013/9/27 Barry Warsaw :
> On Sep 26, 2013, at 02:30 PM, Nick Coghlan wrote:
>
>>- the module name should be "_ensurepip" in all versions
>>- the PEP should explicitly state that the "don't remove _ensurepip
>>and it's wheel files" caveat for redistributors applies only in 3.4+
>>(where removing it will break pyvenv)
>
> I'm sorry that I probably won't be able to engage more on this thread, but I
> think my points should be fairly well understood by the PEP czar and RM.
> Should the PEP be accepted, I think both of these are good changes.

And FWIW, I generally agree with Barry about adding things to 2.7.


-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Brett Cannon 
On Fri, Sep 27, 2013 at 5:16 PM, Zachary Ware
wrote:

> On Fri, Sep 27, 2013 at 3:29 PM, Donald Stufft  wrote:
> >
> 
> >
> > If it lives in the source tree how are you going to provent it from
> existing when someone installs on Linux? OSX? One of the BSDs?
>
> If someone is building their own Python from source--regardless of
> platform--they're obviously going to have _ensurepip available one way
> or another, and such users will need to have it available to match the
> capabilities of the installer (or create their own).  But if you're
> building your own Python, you should already know enough about what's
> going on to know when and whether _ensurepip should be used and how.
> On the other hand, when you use an installer (be it Windows, OSX, or
> otherwise), you really only need _ensurepip one time, ever: at install
> time.  Even then, you don't actually need to know anything about
> _ensurepip at all, just whether to check the box or not.  If you
> decide you need it later, you can always re-install.
>
> > It seems to me your [Terry's] proposal is to add the _ensurepip module…
> except when they install it via Windows installer.
>
> The way I read Terry's proposal, it is to never add the _ensurepip
> *module*, but to use (or make available, whichever makes sense in a
> given case) the _ensurepip *script* when it is requested at
> install-time: specifically, put _ensurepip.py in Tools/scripts, PC/,
> Mac/, or really anywhere but Lib/ so that builders can find it, but
> Python can't.  In other words, don't make "import _ensurepip" possible
> out of the box, and a lot of the "don't add new features in
> maintenance releases" blockade disappears, because you aren't actually
> adding any new capability to Python itself or its standard library.
>
> Of course, this proposal only applies to 2.7/3.3.  Since _ensurepip
> will be used for venv as well as initial install in 3.4, it should be
> a full-blown stdlib module in that version, probably even without the
> leading underscore.
>

That's how I read the proposal as well. If that works then great, otherwise
naming it _ensurepip in 2.7/3.3 should be enough to warn anyone that they
are playing with fire. I think Martin, Ned, etc. would need to weigh in on
whether it's at all an issue having the ensurepip script somewhere that
doesn't get installed but executable from the installer is at all an issue.
For source it can just be in Tools for 2.7/3.3 if that's the route chosen.

Regardless, one of these two options is enough and I suspect we can stop
debating and let Martin make his BDFAP decision.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio

2013-09-27 Thread Brett Cannon 
On Fri, Sep 27, 2013 at 6:33 PM, Guido van Rossum  wrote:

> I've been looking at my progress with Tulip and the 3.4 release schedule
> (PEP 429) and it looks like I will have to do some kind of sprint to get it
> into the release in time for beta 1, which is planned for Nov 24. Ideally
> I'd get it into alpha 4, which is scheduled for Oct 20 -- that's in about
> three weeks, and probably too tight.
>
> Even Nov 24 is aggressive, because the PEP (PEP 3156) hasn't even been
> discussed formally, let alone accepted! Fortunately I'm pretty happy with
> most of the APIs defined in the PEP -- there are some holes but I expect no
> big changes at this point.
>
> It's clear that the only way we can get this into the stdlib is to mark it
> as provisional, per PEP 411. That's fine with me. I expect that the kind of
> changes the code will see between the 3.4 and 3.5 releases are well within
> the bounds of the expectations set by that PEP -- while it is clear that
> everything is possible (even withdrawal), the most likely outcome is that
> the API will be extended or tweaked at most, and not significantly changed
> in a backward compatible way -- without completely ruling out that some
> part of the API may deserve a serious overhaul based on experience. That's
> exactly how I feel about Tulip.
>
> I propose that the new library will be named asyncio. It would be odd if
> we kept the name tulip (stdlib modules rarely have "creative" names), and
> "asynchronous I/O" seems to cover the contents quite well.
>
> I propose that we do the bikeshedding about the API on the
> [email protected] mailing list; I'm not sure what we would
> gain by holding the discussion on python-dev (although clearly we should
> report back here with important milestones in the review). I will post a
> message with the kick-off there.
>
> I hope people will respect my choice of venue, and limit themselves to
> procedural issued on python-dev. E.g. it's fine to debate on python-dev
> whether I'm overstepping my BDFL authority here, or whether the proposed
> API is of sufficiently wide appeal. But I'd prefer to discuss e.g. the
> return type of start_serving() or the choice of yield-from over yield on
> python-tulip.
>

I don't see any issue with redirecting the discussion. python-tulip@ is
acting like a SIG for the module, so no real precedent beyond it not being
hosted as a mail.python.org list.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Donald Stufft 

On Sep 27, 2013, at 9:20 PM, Brett Cannon  wrote:

> 
> 
> 
> On Fri, Sep 27, 2013 at 5:16 PM, Zachary Ware  
> wrote:
> On Fri, Sep 27, 2013 at 3:29 PM, Donald Stufft  wrote:
> >
> 
> >
> > If it lives in the source tree how are you going to provent it from 
> > existing when someone installs on Linux? OSX? One of the BSDs?
> 
> If someone is building their own Python from source--regardless of
> platform--they're obviously going to have _ensurepip available one way
> or another, and such users will need to have it available to match the
> capabilities of the installer (or create their own).  But if you're
> building your own Python, you should already know enough about what's
> going on to know when and whether _ensurepip should be used and how.
> On the other hand, when you use an installer (be it Windows, OSX, or
> otherwise), you really only need _ensurepip one time, ever: at install
> time.  Even then, you don't actually need to know anything about
> _ensurepip at all, just whether to check the box or not.  If you
> decide you need it later, you can always re-install.
> 
> > It seems to me your [Terry's] proposal is to add the _ensurepip module… 
> > except when they install it via Windows installer.
> 
> The way I read Terry's proposal, it is to never add the _ensurepip
> *module*, but to use (or make available, whichever makes sense in a
> given case) the _ensurepip *script* when it is requested at
> install-time: specifically, put _ensurepip.py in Tools/scripts, PC/,
> Mac/, or really anywhere but Lib/ so that builders can find it, but
> Python can't.  In other words, don't make "import _ensurepip" possible
> out of the box, and a lot of the "don't add new features in
> maintenance releases" blockade disappears, because you aren't actually
> adding any new capability to Python itself or its standard library.
> 
> Of course, this proposal only applies to 2.7/3.3.  Since _ensurepip
> will be used for venv as well as initial install in 3.4, it should be
> a full-blown stdlib module in that version, probably even without the
> leading underscore.
> 
> That's how I read the proposal as well. If that works then great, otherwise 
> naming it _ensurepip in 2.7/3.3 should be enough to warn anyone that they are 
> playing with fire. I think Martin, Ned, etc. would need to weigh in on 
> whether it's at all an issue having the ensurepip script somewhere that 
> doesn't get installed but executable from the installer is at all an issue. 
> For source it can just be in Tools for 2.7/3.3 if that's the route chosen.
> 
> Regardless, one of these two options is enough and I suspect we can stop 
> debating and let Martin make his BDFAP decision.


Yes, no matter which way the decision for 2.7 and 3.3 goes the proposal is for 
"ensurepip" in 3.4+

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Monty Taylor 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 09/27/2013 10:50 PM, Donald Stufft wrote:
> 
> On Sep 27, 2013, at 9:20 PM, Brett Cannon  > wrote:
> 
>> 
>> 
>> 
>> On Fri, Sep 27, 2013 at 5:16 PM, Zachary Ware 
>> > > wrote:
>> 
>> On Fri, Sep 27, 2013 at 3:29 PM, Donald Stufft > > wrote:
>>> 
>> 
>>> 
>>> If it lives in the source tree how are you going to provent it
>> from existing when someone installs on Linux? OSX? One of the
>> BSDs?
>> 
>> If someone is building their own Python from source--regardless
>> of platform--they're obviously going to have _ensurepip available
>> one way or another, and such users will need to have it available
>> to match the capabilities of the installer (or create their own).
>> But if you're building your own Python, you should already know
>> enough about what's going on to know when and whether _ensurepip
>> should be used and how. On the other hand, when you use an
>> installer (be it Windows, OSX, or otherwise), you really only
>> need _ensurepip one time, ever: at install time.  Even then, you
>> don't actually need to know anything about _ensurepip at all,
>> just whether to check the box or not.  If you decide you need it
>> later, you can always re-install.
>> 
>>> It seems to me your [Terry's] proposal is to add the
>>> _ensurepip
>> module? except when they install it via Windows installer.
>> 
>> The way I read Terry's proposal, it is to never add the
>> _ensurepip *module*, but to use (or make available, whichever
>> makes sense in a given case) the _ensurepip *script* when it is
>> requested at install-time: specifically, put _ensurepip.py in
>> Tools/scripts, PC/, Mac/, or really anywhere but Lib/ so that
>> builders can find it, but Python can't.  In other words, don't
>> make "import _ensurepip" possible out of the box, and a lot of
>> the "don't add new features in maintenance releases" blockade
>> disappears, because you aren't actually adding any new capability
>> to Python itself or its standard library.
>> 
>> Of course, this proposal only applies to 2.7/3.3.  Since
>> _ensurepip will be used for venv as well as initial install in
>> 3.4, it should be a full-blown stdlib module in that version,
>> probably even without the leading underscore.
>> 
>> 
>> That's how I read the proposal as well. If that works then
>> great, otherwise naming it _ensurepip in 2.7/3.3 should be enough
>> to warn anyone that they are playing with fire. I think Martin,
>> Ned, etc. would need to weigh in on whether it's at all an issue
>> having the ensurepip script somewhere that doesn't get installed
>> but executable from the installer is at all an issue. For source
>> it can just be in Tools for 2.7/3.3 if that's the route chosen.
>> 
>> Regardless, one of these two options is enough and I suspect we
>> can stop debating and let Martin make his BDFAP decision.
> 
> Yes, no matter which way the decision for 2.7 and 3.3 goes the
> proposal is for "ensurepip" in 3.4+

I'm in favor of whatever causes it to get available in 2.7/3.3 in a
way that's predictable. OpenStack is both very highly invested in pip
installation of software and dependencies and also seemingly
maniacally obsessed with continuing to support the older pythons
people have. (eek, we have to support 2.6 until a new RHEL comes out)

To that end, we wind up bootstrapping into pip via distro packages,
but then it's too old, so then people pip install -U pip - systemwide,
so then pip gets broken on redhat and weird on ubuntu because of fail,
and then they get angry and start yelling and I have to go hide in a hole.

If we could start, in tooling, depending on some predictable manner
other than the distros to bootstrap into a sensible and modern pip, I
believe my life would be so much better that I might grow a herd of
unicorns.

Monty
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlJGRTgACgkQ2Jv7/VK1RgF3PQCg18X5gBomDNvI0zTUcFJyN5As
misAoOcnFdJYpAM8ur/lfDhKFGxh4VmQ
=BuJf
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Stephen J. Turnbull 
Nick Coghlan writes:

 > You have confirmed my belief that your model is incorrect.

*shrug*  I just think the risks are higher than acknowledged (just
because you have so far failed to imagine a problem doesn't mean it
won't appear), and that the meta effect that "Even Guido admits that
Python 3 isn't ready for prime time" is perverse.  We know, even those
who have written blanket statements to that effect in this thread,
that that is false unless conditioned on specific applications.

I understand that the real motivation is that it's churlish to not
relieve the pain of users who have decided for their own good reasons
to use Python 2.7, and perverse to ignore the needs of the teachers
who are going to educate the users about Python 3 at the time they
consider appropriate.  But the meta-message *received* by the public
is not going to accurately reflect that motivation, and is not going
to be helpful in encouraging those who already *can* move to Python 3
to do so.

Anyway, clearly this exception is heading for approval, and the PEP
with it.  I recommend that the "Feature addition in maintenance
releases" section be amended to read in its entirety:

The additions of the new module to the standard library in the
maintenance releases of 2.7 and 3.3 were granted explicit
exceptions to the rule "no new features in maintenance releases."
These exceptions were explicitly discussed, and approved in
consultation with the affected release managers, separately from
the rest of the PEP.  They do not represent a change in policy,
and must not be considered a precedent for other such exceptions.

Just the facts, ma'am.  It's a bad idea to include bullshit about the
benefit-cost ratio, because it will be cited in future requests for
similar exceptions.  To the extent that people interpret this as a
forecast and support for a long life for Python 2.7, there is
substantial risk of such requests.


Footnotes: 
[1]  I do it that way myself, always with the most recent Python 3,
but haven't yet gotten to the point of needing "pip" (use cases that
happen to be met by the stdlib).
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Donald Stufft 

On Sep 27, 2013, at 11:48 PM, "Stephen J. Turnbull"  wrote:

> Nick Coghlan writes:
> 
>> You have confirmed my belief that your model is incorrect.
> 
> *shrug*  I just think the risks are higher than acknowledged (just
> because you have so far failed to imagine a problem doesn't mean it
> won't appear), and that the meta effect that "Even Guido admits that
> Python 3 isn't ready for prime time" is perverse.  We know, even those
> who have written blanket statements to that effect in this thread,
> that that is false unless conditioned on specific applications.

I haven't seen anyone say Python 3 isn't ready to be used, just that it
makes more sense for beginners to use 2.7, and I think it does still.
Porting libraries from 2.x to 3.x and translaing the existing corpus of
tutorials, tips, posts, etc isn't a trivial task and one that beginners 
are unlikely to grok.

> 
> I understand that the real motivation is that it's churlish to not
> relieve the pain of users who have decided for their own good reasons
> to use Python 2.7, and perverse to ignore the needs of the teachers
> who are going to educate the users about Python 3 at the time they
> consider appropriate.  But the meta-message *received* by the public
> is not going to accurately reflect that motivation, and is not going
> to be helpful in encouraging those who already *can* move to Python 3
> to do so.
> 
> Anyway, clearly this exception is heading for approval, and the PEP
> with it.  I recommend that the "Feature addition in maintenance
> releases" section be amended to read in its entirety:
> 
>The additions of the new module to the standard library in the
>maintenance releases of 2.7 and 3.3 were granted explicit
>exceptions to the rule "no new features in maintenance releases."
>These exceptions were explicitly discussed, and approved in
>consultation with the affected release managers, separately from
>the rest of the PEP.  They do not represent a change in policy,
>and must not be considered a precedent for other such exceptions.
> 
> Just the facts, ma'am.  It's a bad idea to include bullshit about the
> benefit-cost ratio, because it will be cited in future requests for
> similar exceptions.  To the extent that people interpret this as a
> forecast and support for a long life for Python 2.7, there is
> substantial risk of such requests.

Maybe my understanding of the PEP process is flawed, but isn't
part of the point of it to codify the *reasons* for the decisions that
were made? That's why they include information about dissenting
opinions and such?

I don't think it's dangerous to cite the reasons the decision was came
to. Perhaps it can be toned down but I think it's useful to document
the discussion. I've got a partially done update that tries to capture
the dissenting opinions as well for completeness sake.

> 
> 
> Footnotes: 
> [1]  I do it that way myself, always with the most recent Python 3,
> but haven't yet gotten to the point of needing "pip" (use cases that
> happen to be met by the stdlib).
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/donald%40stufft.io


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio

2013-09-27 Thread Nick Coghlan 
It sounds like a reasonable approach to me.

In terms of naming, would you consider "concurrent.asyncio"? When we
created that parent namespace for futures, one of the other suggested
submodules discussed was the standard event loop API.

Cheers,
Nick.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

2013-09-27 Thread Nick Coghlan 
On 28 Sep 2013 14:12, "Donald Stufft"  wrote:
>
>
> On Sep 27, 2013, at 11:48 PM, "Stephen J. Turnbull" 
wrote:
>
> > Nick Coghlan writes:
> >
> >> You have confirmed my belief that your model is incorrect.
> >
> > *shrug*  I just think the risks are higher than acknowledged (just
> > because you have so far failed to imagine a problem doesn't mean it
> > won't appear), and that the meta effect that "Even Guido admits that
> > Python 3 isn't ready for prime time" is perverse.  We know, even those
> > who have written blanket statements to that effect in this thread,
> > that that is false unless conditioned on specific applications.
>
> I haven't seen anyone say Python 3 isn't ready to be used, just that it
> makes more sense for beginners to use 2.7, and I think it does still.
> Porting libraries from 2.x to 3.x and translaing the existing corpus of
> tutorials, tips, posts, etc isn't a trivial task and one that beginners
> are unlikely to grok.
>
> >
> > I understand that the real motivation is that it's churlish to not
> > relieve the pain of users who have decided for their own good reasons
> > to use Python 2.7, and perverse to ignore the needs of the teachers
> > who are going to educate the users about Python 3 at the time they
> > consider appropriate.  But the meta-message *received* by the public
> > is not going to accurately reflect that motivation, and is not going
> > to be helpful in encouraging those who already *can* move to Python 3
> > to do so.
> >
> > Anyway, clearly this exception is heading for approval, and the PEP
> > with it.  I recommend that the "Feature addition in maintenance
> > releases" section be amended to read in its entirety:
> >
> >The additions of the new module to the standard library in the
> >maintenance releases of 2.7 and 3.3 were granted explicit
> >exceptions to the rule "no new features in maintenance releases."
> >These exceptions were explicitly discussed, and approved in
> >consultation with the affected release managers, separately from
> >the rest of the PEP.  They do not represent a change in policy,
> >and must not be considered a precedent for other such exceptions.
> >
> > Just the facts, ma'am.  It's a bad idea to include bullshit about the
> > benefit-cost ratio, because it will be cited in future requests for
> > similar exceptions.  To the extent that people interpret this as a
> > forecast and support for a long life for Python 2.7, there is
> > substantial risk of such requests.
>
> Maybe my understanding of the PEP process is flawed, but isn't
> part of the point of it to codify the *reasons* for the decisions that
> were made? That's why they include information about dissenting
> opinions and such?
>
> I don't think it's dangerous to cite the reasons the decision was came
> to. Perhaps it can be toned down but I think it's useful to document
> the discussion. I've got a partially done update that tries to capture
> the dissenting opinions as well for completeness sake.

We'll put something in pointing out that accepting this change actually
makes it even *harder* to advocate for further feature additions in Python
2.7 maintenance releases as there is *zero* chance of backporting language
changes, and this PEP means library and builtin updates can easily be a pip
install away if someone is willing to create the backport and put it on
PyPI (Brandon Rhodes already created the "backports" namespace package as a
common home for such efforts, or there's the "2" suffix that has been used
in a couple of cases).

Cheers,
Nick.

>
> >
> >
> > Footnotes:
> > [1]  I do it that way myself, always with the most recent Python 3,
> > but haven't yet gotten to the point of needing "pip" (use cases that
> > happen to be met by the stdlib).
> > ___
> > Python-Dev mailing list
> > [email protected]
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
>
>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
DCFA
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com