Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

2013-10-10 Thread Nick Coghlan 
On 10 Oct 2013 12:40, "Greg Ewing"  wrote:
>
> On 10/10/13 11:57, Nick Coghlan wrote:
>>
>> PEP title: Representation of positional-only parameters
>
>
> Something like "Notation for documenting positional-only parameters"
> would make it even clearer that this is not a proposal for adding
> to the syntax of the language.

It's more than that though, since pydoc and inspect will both emit the
chosen format, and it's entirely possible inspect.Signature will grow an
alternative constructor that consumes it.

Cheers,
Nick.

>
> --
> Greg
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%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] inspect() and dir()

2013-10-10 Thread Nick Coghlan 
On 10 Oct 2013 14:32, "Ethan Furman"  wrote:
>
> On 10/09/2013 03:36 PM, Nick Coghlan wrote:
>
>> On 10 Oct 2013 08:07, "Ethan Furman" wrote:
>>>
>>> On 10/09/2013 02:46 PM, Nick Coghlan wrote:

 On 10 Oct 2013 03:39, "Ethan Furman" wrote:
>
>
> My apologies.  I am actually talking about the module.  I meant
>  inspect.get_members() and inspect.classify_class_attrs(), which,
>  as near as I can tell, are the only two functions in inspect that
>  attempt to retrieve/look at all of an object's attributes.


 Those have to depend on __dir__ so classes (especially proxies)
  can accurately report *extra* dynamically accessible names.
>>>
>>>
>>> Indeed, my rough idea is to use the results of the new dir() and
>>>  combining that with the results of the old dir().  The use case
>>>  being that some classes *ahem* Enum *ahem* may report *less* than
>>>  is actually available, but introspection should reveal whatever is
>>>  there even if dir() is not reporting it.
>>
>>
>> Not necessarily. For autocompletion, for example, you probably
>> only want the public stuff. That's why I'm inclined to suggest
>>  the existing functions should continue to only report advertised
>> attributes, with a separate introspection API that tries harder
>>  to find all accessible attributes (potentially including those
>> from the metaclass). That way users can choose the one most
>>  appropriate to their use case, as well as being able to use the
>>  latter to help test custom dir support.
>
>
> That makes sense.
>
> So what should the new functions be called?  get_all_members and
classify_all_class_attrs ?

Yeah, those work for me. The only way they should miss anything is if
attribute lookup is customised to offer extra dynamic attributes without
implementing custom dir support.

Cheers,
Nick.

>
>
> --
> ~Ethan~
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%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] Python startup time

2013-10-10 Thread Christian Heimes 
Am 10.10.2013 02:18, schrieb Eric Snow:
> On Wed, Oct 9, 2013 at 8:30 AM, Christian Heimes
>  wrote:
>> The os module imports MutableMapping from collections.abc. That
>> import adds collections, collections.abc and eight more modules.
>> I'm not sure if we can do anything about it, though.
> 
> Well, that depends on how much we want to eliminate those 10
> imports. :)  Both environ and environb could be turned into lazy
> wrappers around an _Environ-created-when-needed.  If we used a
> custom module type for os [1], then adding descriptors for the two
> attributes is a piece of cake.  As it is, with a little metaclass
> magic (or even with explicit wrapping of the various dunder
> methods), we could drop those 10 imports from startup.

We don't have to use a custom module type to get rid of these imports
(but I like to get my hands a piece of chocolate cake *g*). We can
either implement yet another mutable mapping class for the os module.
That would remove the dependency on collections.abc.

Or we have to juggle the modules a bit so we can get to MutableMapping
without the extra stuff from collections.__init__. The abc and
_weakset modules are already loaded by the io module. Only
collections.__init__ imports _collections, operator, keyword, heapq,
itertools and reprlib.

I implemented both as an experiment. A lean and mean MutableMapping
works but it involves some code duplication. Next I moved
collections.abc to its former place _abcoll and installed a new
collections.abc module as facade.

$ hg mv Lib/collections/abc.py Lib/_abcoll.py
$ echo "from _abcoll import *" > Lib/collections/abc.py
$ echo "from _abcoll import __all__" >> Lib/collections/abc.py
$ sed -i "s/collections\.abc/_abcoll/" Lib/os.py


With three additional patches I'm down 19 modules:

$ ./python -c "import sys; print(len(sys.modules))"
34
$ hg revert --all .
$ ./python -c "import sys; print(len(sys.modules))"
53

Christian
___
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] Python startup time

2013-10-10 Thread R. David Murray 
On Thu, 10 Oct 2013 07:41:19 +0300, yoav glazner  wrote:
> I'm not sure Droping imports is the best way to go, since every python
> script/app will import common modules right on the start and it will still
> seem like the interpeter boot is slow.
> 
> making modules load faster seems like a better approch

Making any of the infrastructure faster is good.  But I certainly have
plenty of CLI scripts that import only os and sys, so reducing the
number of modules imported will be a win for me.

(Now, granted, a lot of those scripts *ought* to import argparse,
which imports a bunch of stuff, but they don't ;)

--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] Python startup time

2013-10-10 Thread Christian Heimes 
Am 10.10.2013 06:41, schrieb yoav glazner:
> I'm not sure Droping imports is the best way to go, since every python
> script/app will import common modules right on the start and it will
> still seem like the interpeter boot is slow.
> 
> making modules load faster seems like a better approch

Not every script uses the re or collections module. Especially short
running and simple Python programs suffer from import overuse. Every
imported module adds extra syscalls and IO, too. These are costly
operations, especially on slow or embedded devices.


Benchmark of 1000 times "python -c ''"

Python 3.4dev with all my experimental patches:

  Avg: 0.705161 -> 0.443613: 1.59x faster

2.7 -> 3.4dev:

  Avg: 0.316177 -> 0.669330: 2.12x slower

2.7 -> 3.4dev with all my patches:

  Avg: 0.314879 -> 0.449556: 1.43x slower

http://pastebin.com/NFrpa7Jh

Ain't bad! The benchmarks were conducted on a fast 8 core machine with SSD.

Christian


___
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] Python startup time

2013-10-10 Thread Dirkjan Ochtman 
On Thu, Oct 10, 2013 at 2:25 PM, Christian Heimes  wrote:
> Benchmark of 1000 times "python -c ''"
>
> Python 3.4dev with all my experimental patches:
>
>   Avg: 0.705161 -> 0.443613: 1.59x faster
>
> 2.7 -> 3.4dev:
>
>   Avg: 0.316177 -> 0.669330: 2.12x slower
>
> 2.7 -> 3.4dev with all my patches:
>
>   Avg: 0.314879 -> 0.449556: 1.43x slower
>
> http://pastebin.com/NFrpa7Jh
>
> Ain't bad! The benchmarks were conducted on a fast 8 core machine with SSD.

This seems promising. What OS are you using? On an older Linux server
with old-style HD's, the difference between 2.7 and 3.2 is much larger
for me:

Avg: 0.0312 -> 0.1422: 4.56x slower

(In this case, I think it might be more useful to report as 0.11s
faster, though.)

Cheers,

Dirkjan
___
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] Python startup time

2013-10-10 Thread Antoine Pitrou 
Le Thu, 10 Oct 2013 14:36:26 +0200,
Dirkjan Ochtman  a écrit :

> On Thu, Oct 10, 2013 at 2:25 PM, Christian Heimes
>  wrote:
> > Benchmark of 1000 times "python -c ''"
> >
> > Python 3.4dev with all my experimental patches:
> >
> >   Avg: 0.705161 -> 0.443613: 1.59x faster
> >
> > 2.7 -> 3.4dev:
> >
> >   Avg: 0.316177 -> 0.669330: 2.12x slower
> >
> > 2.7 -> 3.4dev with all my patches:
> >
> >   Avg: 0.314879 -> 0.449556: 1.43x slower
> >
> > http://pastebin.com/NFrpa7Jh
> >
> > Ain't bad! The benchmarks were conducted on a fast 8 core machine
> > with SSD.
> 
> This seems promising. What OS are you using? On an older Linux server
> with old-style HD's, the difference between 2.7 and 3.2 is much larger
> for me:

3.2 isn't the same as 3.4.

Thanks Christian for doing this, this is promising!

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] Python startup time

2013-10-10 Thread Victor Stinner 
Hi,

In an old issue, I proposed a change to not load the sysconfig module
when it's not needed. Nobody reviewed the patch, the issue was closed.

http://bugs.python.org/issue14057

When -s or -I option is used, we may skip completly the sysconfig
module. (It's already the case when -S is used.)

By the way, we should probably remove the site module. It's a pain for
the startup time :-)

Victor


2013/10/10 Christian Heimes :
> Am 10.10.2013 02:18, schrieb Eric Snow:
>> On Wed, Oct 9, 2013 at 8:30 AM, Christian Heimes
>>  wrote:
>>> The os module imports MutableMapping from collections.abc. That
>>> import adds collections, collections.abc and eight more modules.
>>> I'm not sure if we can do anything about it, though.
>>
>> Well, that depends on how much we want to eliminate those 10
>> imports. :)  Both environ and environb could be turned into lazy
>> wrappers around an _Environ-created-when-needed.  If we used a
>> custom module type for os [1], then adding descriptors for the two
>> attributes is a piece of cake.  As it is, with a little metaclass
>> magic (or even with explicit wrapping of the various dunder
>> methods), we could drop those 10 imports from startup.
>
> We don't have to use a custom module type to get rid of these imports
> (but I like to get my hands a piece of chocolate cake *g*). We can
> either implement yet another mutable mapping class for the os module.
> That would remove the dependency on collections.abc.
>
> Or we have to juggle the modules a bit so we can get to MutableMapping
> without the extra stuff from collections.__init__. The abc and
> _weakset modules are already loaded by the io module. Only
> collections.__init__ imports _collections, operator, keyword, heapq,
> itertools and reprlib.
>
> I implemented both as an experiment. A lean and mean MutableMapping
> works but it involves some code duplication. Next I moved
> collections.abc to its former place _abcoll and installed a new
> collections.abc module as facade.
>
> $ hg mv Lib/collections/abc.py Lib/_abcoll.py
> $ echo "from _abcoll import *" > Lib/collections/abc.py
> $ echo "from _abcoll import __all__" >> Lib/collections/abc.py
> $ sed -i "s/collections\.abc/_abcoll/" Lib/os.py
>
>
> With three additional patches I'm down 19 modules:
>
> $ ./python -c "import sys; print(len(sys.modules))"
> 34
> $ hg revert --all .
> $ ./python -c "import sys; print(len(sys.modules))"
> 53
>
> Christian
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/victor.stinner%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] Python startup time

2013-10-10 Thread Benjamin Peterson 
2013/10/9 Antoine Pitrou :
> Le Wed, 9 Oct 2013 10:29:30 +0200,
> Antoine Pitrou  a écrit :
>> Le Tue, 8 Oct 2013 15:43:40 -0400,
>> Benjamin Peterson  a écrit :
>>
>> > 2013/10/8 R. David Murray :
>> > > In this context, if we'd been *really* smart-lazy in CPython
>> > > development, we'd have kept the memory and startup-time
>> > > and...well, we probably do pretty well on CPU actually...smaller,
>> > > so that when smartphones came along Python would have been the
>> > > first high level language used on them, because it fit.  Then
>> > > we'd all be able to be *much* lazier now :)
>> >
>> > Even on desktop, startup time leaves a lot to be desired.
>>
>> That's true. Anyone have any ideas to improve it?
>
> It's difficult to identify significant contributors but some possible
> factors:
> - marshal.loads() has become twice slower in 3.x (compared to 2.7)
> - instantiating a class is slow (type('foo', (), {}) takes around 25ms
>   here)

Do you mean microsecond?

 $ ./python -m timeit "type('foo', (), {})"
1 loops, best of 3: 25.9 usec per loop


-- 
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] Python startup time

2013-10-10 Thread Antoine Pitrou 
Le Thu, 10 Oct 2013 10:26:25 -0400,
Benjamin Peterson  a écrit :
> 2013/10/9 Antoine Pitrou :
> > Le Wed, 9 Oct 2013 10:29:30 +0200,
> > Antoine Pitrou  a écrit :
> >> Le Tue, 8 Oct 2013 15:43:40 -0400,
> >> Benjamin Peterson  a écrit :
> >>
> >> > 2013/10/8 R. David Murray :
> >> > > In this context, if we'd been *really* smart-lazy in CPython
> >> > > development, we'd have kept the memory and startup-time
> >> > > and...well, we probably do pretty well on CPU
> >> > > actually...smaller, so that when smartphones came along Python
> >> > > would have been the first high level language used on them,
> >> > > because it fit.  Then we'd all be able to be *much* lazier
> >> > > now :)
> >> >
> >> > Even on desktop, startup time leaves a lot to be desired.
> >>
> >> That's true. Anyone have any ideas to improve it?
> >
> > It's difficult to identify significant contributors but some
> > possible factors:
> > - marshal.loads() has become twice slower in 3.x (compared to 2.7)
> > - instantiating a class is slow (type('foo', (), {}) takes around
> > 25ms here)
> 
> Do you mean microsecond?
> 
>  $ ./python -m timeit "type('foo', (), {})"
> 1 loops, best of 3: 25.9 usec per loop

Yes, I meant that.

cheers

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] Python startup time

2013-10-10 Thread Serhiy Storchaka 

10.10.13 15:25, Christian Heimes написав(ла):

Benchmark of 1000 times "python -c ''"


What about "python -S -c ''"?


___
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] Fix IO Encoding issue for embedded Python under Windows - Issue16129

2013-10-10 Thread Bastien Montagne 

Hi Py Devs,

As this is my first mail here, first a short presentation: my name is 
Bastien Montagne (aka mont29), I live in France, and I’ve been using 
Python for a fair amount of years now in various projects, amongst which 
Blender 3D software. I’m also a Blender dev (C & Py) since a few years.


Now to the topic, to summarize http://bugs.python.org/issue16129 , an 
application dynamically linking against Python under MS-Windows has no 
way to control Python's environment, and hence cannot set 
PYTHONIOENCODING to get another encoding than default Windows' console 
(which is usually 8bit, like cp437). This is really annoying under 
Blender, as we use utf-8 strings, users having e.g. "special" chars in 
their file paths keep getting python errors instead of nice prints…


Following Nick Coghlan’s suggestions, I made a patch which solves that 
issue by adding Py_SetStandardStreamEncoding() to the API, which allows 
embedding code to directly specify standard IO encodings. So now I’m 
waiting for reviews & comments from py devs, in the hope that this can 
make it into python code before 3.4 feature freeze (patch: 
http://bugs.python.org/file31985/setstdio.diff ).


Best regards,
Bastien
___
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] Python startup time

2013-10-10 Thread Brett Cannon 
On Thu, Oct 10, 2013 at 9:38 AM, Antoine Pitrou  wrote:

> Le Thu, 10 Oct 2013 14:36:26 +0200,
> Dirkjan Ochtman  a écrit :
>
> > On Thu, Oct 10, 2013 at 2:25 PM, Christian Heimes
> >  wrote:
> > > Benchmark of 1000 times "python -c ''"
> > >
> > > Python 3.4dev with all my experimental patches:
> > >
> > >   Avg: 0.705161 -> 0.443613: 1.59x faster
> > >
> > > 2.7 -> 3.4dev:
> > >
> > >   Avg: 0.316177 -> 0.669330: 2.12x slower
> > >
> > > 2.7 -> 3.4dev with all my patches:
> > >
> > >   Avg: 0.314879 -> 0.449556: 1.43x slower
> > >
> > > http://pastebin.com/NFrpa7Jh
> > >
> > > Ain't bad! The benchmarks were conducted on a fast 8 core machine
> > > with SSD.
> >
> > This seems promising. What OS are you using? On an older Linux server
> > with old-style HD's, the difference between 2.7 and 3.2 is much larger
> > for me:
>
> 3.2 isn't the same as 3.4.
>

And I think that is a key point as imports sped up a good deal in Python
3.3 thanks to the stat caching. So if you want to compare 3.4 to 3.3 that
makes sense. And if you want to compare 2.7 to 3.4 as a selling point as
startup is the worst benchmark performer in that comparison then fine. But
otherwise leave 3.0 - 3.2 out of the discussion as they are red herrings.

And as to the suggestion of speeding up import itself: good luck with that
without changing semantics. =)
___
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] Python startup time

2013-10-10 Thread Eric Snow 
On Thu, Oct 10, 2013 at 4:18 AM, Christian Heimes  wrote:
> We don't have to use a custom module type to get rid of these imports
> (but I like to get my hands a piece of chocolate cake *g*). We can
> either implement yet another mutable mapping class for the os module.
> That would remove the dependency on collections.abc.
>
> Or we have to juggle the modules a bit so we can get to MutableMapping
> without the extra stuff from collections.__init__. The abc and
> _weakset modules are already loaded by the io module. Only
> collections.__init__ imports _collections, operator, keyword, heapq,
> itertools and reprlib.

I've created a ticket for the os/collections issue:
http://bugs.python.org/issue19218.  I also put a patch on there that
takes a metaclass approach.  It removes the need to fiddle with the
collections package or to implement the other MutableMapping methods
(along with the view classes) on _Environ.

-eric
___
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] [Python-checkins] peps: Revise PEP 453 to be docs-only for 2.7 & 3.3

2013-10-10 Thread Terry Reedy 

On 10/10/2013 10:48 AM, nick.coghlan wrote:

http://hg.python.org/peps/rev/405b80d54b7d
changeset:   5188:405b80d54b7d
user:Nick Coghlan 
date:Fri Oct 11 00:47:47 2013 +1000
summary:
   Revise PEP 453 to be docs-only for 2.7 & 3.3

- all functional changes are now 3.4 only
- still proposes docs changes for 2.7 & 3.3
- notes current effort to create a Windows installer for pip
- notes possibility of a future PEP to provide a combined
   CPython 2.7, pip and Python Launcher installer from python.org



+`Installing Python Modules `__ guide in
+Python 2.7, 3.3 and 3.4 be updated to officially recommend the use of ``pip``
+as the default installer for Python packages, and that appropriate technical
+changes be made in Python 3.4 to provide ``pip`` by default in support of
+that recommendation.


Does one need a separate installation of pip for each Python version or 
is pip 'separate' enough that one installation works for all Python 
versions? Is the answer to this the same on all systems? If the answer 
is 'one' and 'yes', the 2.7 and 3.3 docs should say that installing 3.4 
also installs pip and that this is all one needs to do.



+While this PEP only proposes documentation changes for Python 2.7, once
+``pip`` has a Windows installer available, a separate PEP will be created
+and submitted proposing the creation and distribution of aggregate installers
+for future CPython 2.7 maintenance releases that combine the CPython,
+``pip`` and Python Launcher for Windows installers into a single download
+(the separate downloads would still remain available - the aggregate
+installers would be provided as a convenience, and as a clear indication
+of the recommended operating environment for Python in Windows systems).


If the combined installer is an optional convenience, I would not think 
a PEP necessary. I am assuming that the combined installer would not add 
a module to /lib any more than two separate installers would, and hence 
would not be adding a feature to 2.7 itself.


--
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] Fix IO Encoding issue for embedded Python under Windows - Issue16129

2013-10-10 Thread Nick Coghlan 
On 11 Oct 2013 01:22, "Bastien Montagne"  wrote:
>
> Hi Py Devs,
>
> As this is my first mail here, first a short presentation: my name is
Bastien Montagne (aka mont29), I live in France, and I’ve been using Python
for a fair amount of years now in various projects, amongst which Blender
3D software. I’m also a Blender dev (C & Py) since a few years.
>
> Now to the topic, to summarize http://bugs.python.org/issue16129 , an
application dynamically linking against Python under MS-Windows has no way
to control Python's environment, and hence cannot set PYTHONIOENCODING to
get another encoding than default Windows' console (which is usually 8bit,
like cp437). This is really annoying under Blender, as we use utf-8
strings, users having e.g. "special" chars in their file paths keep getting
python errors instead of nice prints…
>
> Following Nick Coghlan’s suggestions, I made a patch which solves that
issue by adding Py_SetStandardStreamEncoding() to the API, which allows
embedding code to directly specify standard IO encodings. So now I’m
waiting for reviews & comments from py devs, in the hope that this can make
it into python code before 3.4 feature freeze (patch:
http://bugs.python.org/file31985/setstdio.diff ).

Sorry for the radio silence - this is on my list to look at before alpha 4.
(The main thing ahead of it on the to do list was the PEP 453 update to
limit the functional changes to 3.4 only, which is now with Donald for
review before we submit it for pronouncement).

However, if someone else wanted to tackle Bastien's patch before I get to
it, I certainly wouldn't complain :)

Cheers,
Nick.

>
> Best regards,
> Bastien
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%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] [Python-checkins] peps: Revise PEP 453 to be docs-only for 2.7 & 3.3

2013-10-10 Thread Nick Coghlan 
On 11 Oct 2013 05:04, "Terry Reedy"  wrote:
>
> On 10/10/2013 10:48 AM, nick.coghlan wrote:
>>
>> http://hg.python.org/peps/rev/405b80d54b7d
>> changeset:   5188:405b80d54b7d
>> user:Nick Coghlan 
>> date:Fri Oct 11 00:47:47 2013 +1000
>> summary:
>>Revise PEP 453 to be docs-only for 2.7 & 3.3
>>
>> - all functional changes are now 3.4 only
>> - still proposes docs changes for 2.7 & 3.3
>> - notes current effort to create a Windows installer for pip
>> - notes possibility of a future PEP to provide a combined
>>CPython 2.7, pip and Python Launcher installer from python.org
>
>
>> +`Installing Python Modules `__ guide
in
>> +Python 2.7, 3.3 and 3.4 be updated to officially recommend the use of
``pip``
>> +as the default installer for Python packages, and that appropriate
technical
>> +changes be made in Python 3.4 to provide ``pip`` by default in support
of
>> +that recommendation.
>
>
> Does one need a separate installation of pip for each Python version or
is pip 'separate' enough that one installation works for all Python
versions? Is the answer to this the same on all systems? If the answer is
'one' and 'yes', the 2.7 and 3.3 docs should say that installing 3.4 also
installs pip and that this is all one needs to do.

pip is version specific (it's just a normal Python package).

>> +While this PEP only proposes documentation changes for Python 2.7, once
>> +``pip`` has a Windows installer available, a separate PEP will be
created
>> +and submitted proposing the creation and distribution of aggregate
installers
>> +for future CPython 2.7 maintenance releases that combine the CPython,
>> +``pip`` and Python Launcher for Windows installers into a single
download
>> +(the separate downloads would still remain available - the aggregate
>> +installers would be provided as a convenience, and as a clear indication
>> +of the recommended operating environment for Python in Windows systems).
>
>
> If the combined installer is an optional convenience, I would not think a
PEP necessary. I am assuming that the combined installer would not add a
module to /lib any more than two separate installers would, and hence would
not be adding a feature to 2.7 itself.

That PEP (if created) would be for publishing such an aggregate installer
from the 2.7 release page on python.org.

Since it would be proposing more work for the creator of the CPython
Windows installers, a PEP seems appropriate.

Cheers,
Nick.

>
> --
> Terry Jan Reedy
>
> ___
> Python-checkins mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-checkins
___
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