Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?
In article , Brett Cannon wrote: > On Fri, Sep 27, 2013 at 5:16 PM, Zachary Ware > wrote: > > 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. Putting an "ensurepip.py" script (with or without the "_") in Tools/ should be fine for the needs of 2.7 and/or 3.3 OS X installers. Without venv in the picture, it doesn't need to do much; the installer build script itself could handle everything without an ensurepip. There are still other changes in the installer that would need to be made, particularly if it is necessary to make the installation of pip (and its dependency, setuptools) optional but all of those would be isolated to the Mac subdirectory. -- Ned Deily, [email protected] ___ 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] PEP 453 (pip bootstrap) TL;DR and Usage Scenario
On Mon, Sep 23, 2013 at 2:15 PM, Nick Coghlan wrote: > With the last round of updates, I believe PEP 453 is ready for > Martin's pronouncement. > > HTML: http://www.python.org/dev/peps/pep-0453/ > Major diffs: http://hg.python.org/peps/rev/b2993450b32a I'd enjoy concise PEP texts, but it is extremely hard to write one, so is it possible to at least add a TL;DR chapter that just shows the concept in 15 seconds without all the gory details? What is the entrypoint in the bootstrap process and knowledge requirements for the user? For the same sake, is it possible to include real world usage scenario as a code paste example of user session. For instance: # --- 001: user reads install instruction on site # 'pip install ' # user executes 'pip install ' on Windows > pip install 'pip' is not recognized as an internal or external command, operable program or batch file. # user .. ? [ ] # user executes 'pip install ' on Ubuntu $ pip install The program 'pip' is currently not installed. You can install it by typing: sudo apt-get install pip $ sudo apt-get install pip # (user has sudo - done) # user doesn't have sudo, command fails # user .. ? [ ] # --- 002: user reads install instruction on site # 'python -m pip install ' $ python -m pip install /usr/bin/python: No module named pip # user .. ? [ ] -- anatoly t. ___ 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
On Sat, 28 Sep 2013 15:59:05 +1000 Nick Coghlan wrote: > 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. -10. Please, let's stop it. 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?
On Fri, Sep 27, 2013 at 6:19 PM, Benjamin Peterson wrote: > 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. > +1. Not to mention the general problem of adding new features in maintenance releases (what? it doesn't work for you? Check it's 2.7.6 and not 2.7.5!) , at this point in the trajectory of Python 3.x and 2.7 it sends a very wrong message. 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] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio
On Sep 27, 2013, at 09:14 PM, Brett Cannon wrote: >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. The PEP process even allows for this formally. Please add a Discussions-To header to PEP 3156. See PEP 1 for details. -Barry ___ 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?
On Sep 28, 2013, at 12:48 PM, Stephen J. Turnbull wrote: >*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. FWIW, +1 > >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. Call this the "Bush v. Gore" amendment. -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
[Python-Dev] toolbar
Hi, I just downloaded Python 3.3 top teach myself how to program, I am new to programming, but the guide I am using requires me to access the toolbar, which I cannot seem to find. How do I find it and have it displayed on the interface? I tried v 3.1 but its still absent. Thank you. ___ 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
On Fri, Sep 27, 2013 at 3: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. > Sounds good. But once it's in stdlib, I think it would be proper to shift the discussion into the normal pydev channels (python-dev, issue tracker, etc.). Is this the plan? 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] toolbar
On 9/28/2013 7:28 AM, Kevin Ngugi wrote: Hi, I just downloaded Python 3.3 top teach myself how to program, I am new to programming, but the guide I am using requires me to access the toolbar, which I cannot seem to find. How do I find it and have it displayed on the interface? I tried v 3.1 but its still absent. Thank you. python-dev is for development of Python. Please ask questions about using Python elsewhere, such as python-list. When you do, say what 'guide' you are using and what 'toolbar' it refers to. I don't know. And please do not answer this email. -- 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] toolbar
On 28/09/2013 12:28, Kevin Ngugi wrote:
Hi, I just downloaded Python 3.3 top teach myself how to program, I am
new to programming, but the guide I am using requires me to access the
toolbar, which I cannot seem to find. How do I find it and have it
displayed on the interface? I tried v 3.1 but its still absent. Thank
you.
This list ("python-dev") is for the development _of_ Python, not _with_
Python, which is "python-list".
Also, you'll need to say what you mean by "the toolbar".
___
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
On Fri, Sep 27, 2013 at 10:59 PM, Nick Coghlan wrote: > 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. > Hm. I want the threading and event world to be very clearly separate and different, since accidentally combining them is disastrous. So the concurrent package is the *last* place where I want asyncio to live. (And I realize there is also some multiprocessing support in that package -- but it still uses threads to wait for things.) -- --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] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio
> On Sep 28, 2013, at 12:59 AM, Nick Coghlan wrote: > > 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. > +1 but up to guido > 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/jnoller%40gmail.com ___ 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
On Sat, Sep 28, 2013 at 9:07 AM, Eli Bendersky wrote: > > > Sounds good. But once it's in stdlib, I think it would be proper to shift > the discussion into the normal pydev channels (python-dev, issue tracker, > etc.). Is this the plan? > Hadn't really thought about that. I think there's a precedent for aspects of Python that have their own mailing list (e.g. import-sig). Also, python-dev is usually pretty hostile about people asking usage questions -- there's no such taboo on the Tulip list. I can certainly see how you wouldn't want to have to look at multiple trackers. Possibly the Tulip tracker could be limited to discussion of the Python 3.3 backport that I hope to maintain in that project. -- --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] toolbar
On 28/09/2013 12:28, Kevin Ngugi wrote: Hi, I just downloaded Python 3.3 top teach myself how to program, I am new to programming, but the guide I am using requires me to access the toolbar, which I cannot seem to find. How do I find it and have it displayed on the interface? I tried v 3.1 but its still absent. Thank you. Further to other replies you might be better off on the tutor mailing list see https://mail.python.org/mailman/listinfo/tutor -- 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] Best practice for documentation for std lib
On 9/22/2013 10:44 PM, Guido van Rossum wrote:
On Sun, Sep 22, 2013 at 7:25 PM, Terry Reedy
('Return' rather than 'Returns' is the current convention.)
That's actually a religious argument which in the stdlib takes no strict
position -- a quick grep shows that both are used, although 'Return' is
more frequent by a 5-to-1 margin.
I wrote 'current convention' not just as a statistical statement, but
as a prescription I had read, even though I did not remember just where.
PEP8 says
"PEP 257 describes good docstring conventions."
I followed that clue found the statement I had read. PEP 257 says
'''
It [the one line docstring] prescribes the function or method's effect
as a command ("Do this", "Return that"), not as a description; e.g.
don't write "Returns the pathname ...".
'''
Whether the reference in PEP 8 makes it a PEP 8 rule? or a 'strict
stdlib position'?
http://bugs.python.org/issue19067 proposes to change rangeobject
docstrings. Is that OK or should the issue be rejected and closed?
--
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] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio
On 29 Sep 2013 02:52, "Guido van Rossum" wrote: > > On Fri, Sep 27, 2013 at 10:59 PM, Nick Coghlan wrote: >> >> 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. > > > Hm. I want the threading and event world to be very clearly separate and different, since accidentally combining them is disastrous. So the concurrent package is the *last* place where I want asyncio to live. (And I realize there is also some multiprocessing support in that package -- but it still uses threads to wait for things.) Makes sense to me! Cheers, Nick. > > -- > --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
