Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

[Stefan Behnel]

Tim Delaney, 27.10.2012 22:53:

On 28 October 2012 07:40, Mark Shannon wrote:

I suspect that stating and loading the .pyc files is responsible for most
of the overhead.
PyRun starts up quite a lot faster thanks to embedding all the modules in
the executable: 
http://www.egenix.com/**products/python/PyRun/

Freezing all the core modules into the executable should reduce start up
time.


That suggests a test to me that the Cython guys might be interested in (or
may well have performed in the past). How much of the stdlib could be
compiled with Cython and used during the startup process?


We have a Jenkins job set up to run the CPython test suite with a compiled 
stdlib:


https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr-stdlib/

Basically, we use pyximport as an import hook that tries to compile Python 
modules on import and then imports the shared library if it worked or the 
original Python module if it failed. A solution that explicitly runs over 
the stdlib and compiles it would be substantially cleaner and more stable.


I don't have numbers for Py3.4 because we currently have a hard crash in 
one of the tests on that platform when compiling recursively on import 
(likely meaning that one of the stdlib modules and/or tests would have to 
be excluded from compilation), but I get 434 automatically compiled stdlib 
modules for the latest Py2.7 branch out of 744 (excluding the test suite). 
And Py3.x code tends to pass as least as well through the compiler, often 
better.


Note that quite a number of modules are excluded accidentally because they 
are already imported as Python modules when Cython starts working. 
Compiling them explicitly would remove that limitation, maybe adding 
another (wild guess) 50 modules or so. Another few are not being compiled 
because the test module that uses them fails to compile. So missing shared 
libraries are not always due to failures to compile that particular Python 
module.


I didn't pay much attention to this part of our integration tests so far - 
a bit of debugging should get the Py3.4 build working.




How much of an
effect would it have on startup times and these benchmarks if
Cython-compiled extensions were used?


Depends on what and how much code you use. If you compile everything into 
one big module that "imports" all of the stdlib when it gets loaded, you'd 
likely loose a lot of time because it would take a while to initialise all 
that useless code on startup. If you keep it separate, it would likely be a 
lot faster because you avoid the interpreter for most of the module startup.


Most Python code runs about 30% faster when compiled, some faster, some 
slower. If you want better numbers, you can start optimising the code by 
giving Cython static type hints. I did that for difflib a while ago, for 
example. Changing two methods made it some 50% faster back then:


http://blog.behnel.de/index.php?p=155

That particular module should compile without changes these days, and you 
can provide the type hints externally, i.e. without modifying the Python 
code itself.




I'm thinking here of elimination of .pyc interpretation and execution (stat
calls would be similar, probably slightly higher).


CPython checks for .so files before looking for .py files and imports are 
absolute by default in Py3, so there should be a slight reduction in stat 
calls. The net result then obviously also depends on how fast your shared 
library loader and linker is, etc., but I doubt that that path is any 
slower than loading and running a .pyc file.


BTW, you'd still get nice stack traces for compiled modules as long as your 
.py files lie right next to your .so files.




To be clear - I'm *not* suggesting Cython become part of the required build
toolchain. But *if* the Cython-compiled extensions prove to be
significantly faster I'm thinking maybe it could become a semi-supported
option (e.g. a HOWTO with the caveat "it worked on this particular system").


Sounds reasonable.

Stefan


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

[Stefan Behnel]

Stefan Behnel, 28.10.2012 08:22:

Tim Delaney, 27.10.2012 22:53:

How much of an effect would it have on startup times and these benchmarks if
Cython-compiled extensions were used?


Depends on what and how much code you use. If you compile everything into
one big module that "imports" all of the stdlib when it gets loaded, you'd
likely loose a lot of time because it would take a while to initialise all
that useless code on startup. If you keep it separate, it would likely be a
lot faster because you avoid the interpreter for most of the module startup.

Most Python code runs about 30% faster when compiled, some faster, some
slower.


Some more unoptimised pure-Python benchmarks, just in case:

2.7:

https://sage.math.washington.edu:8091/hudson/job/cython-devel-pybenchmarks-py27/lastSuccessfulBuild/artifact/bench_chart.html

3.3:

https://sage.math.washington.edu:8091/hudson/job/cython-devel-pybenchmarks-py3k/lastSuccessfulBuild/artifact/bench_chart.html

Note that the 3.3 benchmarks are not entirely up to date, the last 
successful run was a month ago (likely due to the branch into 3.4 which we 
use since then). Didn't have time to fix them yet.


Note also that the variations are pretty high from run to run as the 
machine that executes them is not a dedicated benchmark server.


Stefan


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (merge 3.2 -> 3.2): null merge

[Georg Brandl]

Not very important, but this is not a null merge, as you can see from the diff 
:)

Georg

Am 17.10.2012 16:33, schrieb andrew.svetlov:
> http://hg.python.org/cpython/rev/16493102f9b1
> changeset:   79798:16493102f9b1
> branch:  3.2
> parent:  79791:98f64cbed2ac
> parent:  79795:a8052ad9752b
> user:Andrew Svetlov 
> date:Wed Oct 17 17:20:46 2012 +0300
> summary:
>   null merge
> 
> files:
>   Doc/using/cmdline.rst |  6 --
>   Misc/ACKS |  1 +
>   2 files changed, 5 insertions(+), 2 deletions(-)
> 
> 
> diff --git a/Doc/using/cmdline.rst b/Doc/using/cmdline.rst
> --- a/Doc/using/cmdline.rst
> +++ b/Doc/using/cmdline.rst
> @@ -379,7 +379,10 @@
>  Environment variables
>  -
>  
> -These environment variables influence Python's behavior.
> +These environment variables influence Python's behavior, they are processed
> +before the command-line switches other than -E.  It is customary that
> +command-line switches override environmental variables where there is a
> +conflict.
>  
>  .. envvar:: PYTHONHOME
>  
> @@ -570,4 +573,3 @@
>  
> If set, Python will print memory allocation statistics every time a new
> object arena is created, and on shutdown.
> -
> diff --git a/Misc/ACKS b/Misc/ACKS
> --- a/Misc/ACKS
> +++ b/Misc/ACKS
> @@ -901,6 +901,7 @@
>  Saskia van Rossum
>  Donald Wallace Rouse II
>  Liam Routt
> +Todd Rovito
>  Craig Rowland
>  Clinton Roy
>  Paul Rubin
> 
> 
> 
> ___
> Python-checkins mailing list
> python-check...@python.org
> http://mail.python.org/mailman/listinfo/python-checkins
> 


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] devguide: Silence Sphinx warning

[Georg Brandl]

Am 19.10.2012 14:06, schrieb nick.coghlan:
> http://hg.python.org/devguide/rev/08f963e19a3e
> changeset:   559:08f963e19a3e
> user:Nick Coghlan 
> date:Fri Oct 19 22:06:19 2012 +1000
> summary:
>   Silence Sphinx warning
> 
> files:
>   setup.rst |  2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
> 
> 
> diff --git a/setup.rst b/setup.rst
> --- a/setup.rst
> +++ b/setup.rst
> @@ -184,7 +184,7 @@
>  '''
>  
>  **Python 3.3** and later use Microsoft Visual Studio 2010.  You can
> -download Microsoft Visual C++ 2010 Express `here
> +download Microsoft Visual C++ 2010 Express `from Microsoft's site
>  
> `_.

JFTR, this is a Docutils warning, not a Sphinx warning, and can also be avoided
by using `...`__ (i.e. two underscores).  The one-underscore form creates a
"target" that you can then reference again from elsewhere; the two-underscore
form doesn't.

cheers,
Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: PEP 430 is Final.

[Barry Warsaw]

On Oct 28, 2012, at 09:21 AM, georg.brandl wrote:

>  PEP 430 is Final.

>From the PEP:

"The existing /py3k/ subpath would be remapped to the new /3/ subpath."

Does "remapped" mean redirects so as not to break the existing py3k urls?  If
so, then cool.

Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: PEP 430 is Final.

[Georg Brandl]

Am 28.10.2012 09:40, schrieb Barry Warsaw:
> On Oct 28, 2012, at 09:21 AM, georg.brandl wrote:
> 
>>  PEP 430 is Final.
> 
> From the PEP:
> 
> "The existing /py3k/ subpath would be remapped to the new /3/ subpath."
> 
> Does "remapped" mean redirects so as not to break the existing py3k urls?  If
> so, then cool.

Yes, /py3k is now a permanent redirect to /3.

The other new URLs are not redirects anymore, so that /2.4/ no longer redirects
to /dev/.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

[Antoine Pitrou]

On Sat, 27 Oct 2012 20:38:58 -0700
"Gregory P. Smith"  wrote:
> One word: profile.
> 
> Looking at stat counts alone rather than measuring the total time spent in
> all types of system calls from strace and profiling is not really useful. ;)

Agreed, but I can't seem to cope properly with gprof. Any suggestion?

> Another thing to keep an eye out for within a startup profile:  how often
> does the gc collect?  our default gc collection thresholds haven't been
> tuned in ages afaik [or am i forgetting something] and I know of
> pathological cases at work where simply doing a gc.disable() before
> importing a bunch of modules (tons of generated protocol buffer code) and
> re-enabling it afterwards speeds up this application's startup way more
> significantly than seems healthy in 2.x... that could be related to the
> particulars of the protobuf module code though.

That's a good suggestion indeed.

Thanks

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (merge 2.6 -> 2.7): merge with 2.6

[Antoine Pitrou]

On Sun, 28 Oct 2012 08:05:00 +0100 (CET)
georg.brandl  wrote:
> http://hg.python.org/cpython/rev/ee33671b2c6a
> changeset:   79995:ee33671b2c6a
> branch:  2.7
> parent:  79983:7ca30af90c11
> parent:  79994:4a17784f2fee
> user:Georg Brandl 
> date:Sun Oct 28 08:06:11 2012 +0100
> summary:
>   merge with 2.6
> 
> files:
>   Doc/tools/sphinxext/static/version_switch.js |  18 +
>   1 files changed, 10 insertions(+), 8 deletions(-)

Is it deliberate for our Javascript code to use 2-space indents?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-ideas] docs.python.org

[Nick Coghlan]

On Sun, Oct 28, 2012 at 5:59 PM, Georg Brandl  wrote:
> Am 27.10.2012 16:40, schrieb Nick Coghlan:
>
 4. We add a notice like the one above to the home page of the 2.7
 docs, announce it on the PSF blog, announce it far and wide
>>>
>>> We also need a solution for URLs that exist for Python 2, but
>>> not for Python 3. Those should be redirected to the Python 2
>>> resource automatically, e.g. URLs pointing to the Python 2 modules
>>> that were renamed in Python 3.
>>>
>>> BTW: Will you write up a PEP for this ?
>>
>> Committed as PEP 430, should show up
>> http://www.python.org/dev/peps/pep-0430 before too long.
>
> Well, with the approval I've seen here, I have absolutely no problem
> with appointing myself PEP Czar and accepting the PEP :)

Heh, asking you to do that was next on my list, so thanks. Did Guido
hide a mind reading device in the time machine? :)

> I'll work on fixing the Apache config.

Huzzah \o/

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] devguide: Silence Sphinx warning

[Nick Coghlan]

On Sun, Oct 28, 2012 at 5:52 PM, Georg Brandl  wrote:
> JFTR, this is a Docutils warning, not a Sphinx warning, and can also be 
> avoided
> by using `...`__ (i.e. two underscores).  The one-underscore form creates a
> "target" that you can then reference again from elsewhere; the two-underscore
> form doesn't.

Ah, useful trick to know, thanks.

Cheers,
Nick.


-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: PEP for updating the URL layout on docs.python.org

[Chris Jerdonek]

On Sat, Oct 27, 2012 at 7:36 AM, nick.coghlan
 wrote:
> http://hg.python.org/peps/rev/c7ba002ca91d
> changeset:   4568:c7ba002ca91d
> user:Nick Coghlan 
> date:Sun Oct 28 00:36:36 2012 +1000
> summary:
>   PEP for updating the URL layout on docs.python.org

> +* ``http://docs.python.org/x/*``
> +* ``http://docs.python.org/x.y/*``
> +* ``http://docs.python.org/release/x.y.z/*``
> +* ``http://docs.python.org/devguide``
> +
> +The ``/x/`` URLs mean "give me the latest documentation for this release
> +series``. Differences relative to previous versions in the release series
> +will be available through "version added" and "version changed" markers.
> +
> +The ``/x.y/`` URLs mean "give me the latest documentation for this release".

It might be worth clarifying what "latest" means for both the "x" and
"x.y" forms.  For example, should "http://docs.python.org/3/"; today
link to the released 3.3.0 version, the in-progress 3.3.1 version, or
the in-progress 3.4.0?

For the "x" form, I think we mean the second because that is what it
points to today, i.e. the in-development version of the highest
released minor version of the major version "x".

There's a slight mismatch with how we're doing it today because
"http://docs.python.org/3/"; shows 3.3.0 in the title even though it's
the in-progress 3.3.1.  The title should perhaps reflect that it's
post 3.3.0 (and similarly for the 2.7 and 3.2 pages).

--Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (merge 2.6 -> 2.7): merge with 2.6

[Georg Brandl]

Am 28.10.2012 12:13, schrieb Antoine Pitrou:
> On Sun, 28 Oct 2012 08:05:00 +0100 (CET)
> georg.brandl  wrote:
>> http://hg.python.org/cpython/rev/ee33671b2c6a
>> changeset:   79995:ee33671b2c6a
>> branch:  2.7
>> parent:  79983:7ca30af90c11
>> parent:  79994:4a17784f2fee
>> user:Georg Brandl 
>> date:Sun Oct 28 08:06:11 2012 +0100
>> summary:
>>   merge with 2.6
>> 
>> files:
>>   Doc/tools/sphinxext/static/version_switch.js |  18 +
>>   1 files changed, 10 insertions(+), 8 deletions(-)
> 
> Is it deliberate for our Javascript code to use 2-space indents?

Yes.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: PEP for updating the URL layout on docs.python.org

[Nick Coghlan]

On Sun, Oct 28, 2012 at 9:34 PM, Georg Brandl  wrote:
> Am 28.10.2012 12:29, schrieb Chris Jerdonek:
>> On Sat, Oct 27, 2012 at 7:36 AM, nick.coghlan
>>  wrote:
>>> http://hg.python.org/peps/rev/c7ba002ca91d
>>> changeset:   4568:c7ba002ca91d
>>> user:Nick Coghlan 
>>> date:Sun Oct 28 00:36:36 2012 +1000
>>> summary:
>>>   PEP for updating the URL layout on docs.python.org
>>
>>> +* ``http://docs.python.org/x/*``
>>> +* ``http://docs.python.org/x.y/*``
>>> +* ``http://docs.python.org/release/x.y.z/*``
>>> +* ``http://docs.python.org/devguide``
>>> +
>>> +The ``/x/`` URLs mean "give me the latest documentation for this release
>>> +series``. Differences relative to previous versions in the release series
>>> +will be available through "version added" and "version changed" markers.
>>> +
>>> +The ``/x.y/`` URLs mean "give me the latest documentation for this 
>>> release".
>>
>> It might be worth clarifying what "latest" means for both the "x" and
>> "x.y" forms.  For example, should "http://docs.python.org/3/"; today
>> link to the released 3.3.0 version, the in-progress 3.3.1 version, or
>> the in-progress 3.4.0?
>
> I understand "latest" to mean "latest stable plus bugfixes".
> I.e., /3/ is 3.3.0+. /dev and /3.4 is 3.4a0.  It might need clarifying
> in the PEP.

Yes, I realised last night that it would be good to be more explicit
about this. The "release" hierarchy should be for versions exactly as
they were released, while the shorter ones draw directly from source
control (and thus may contain fixes which otherwise haven't been
released yet).

I updated the PEP to describe what Georg has put in place more
explicitly (initially I was going to propose a change to the way /dev/
URLs are handled, but then I realised what is already there made more
sense).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: PEP for updating the URL layout on docs.python.org

[Chris Jerdonek]

On Sun, Oct 28, 2012 at 4:34 AM, Georg Brandl  wrote:
> Am 28.10.2012 12:29, schrieb Chris Jerdonek:
> ...
> I understand "latest" to mean "latest stable plus bugfixes".
> I.e., /3/ is 3.3.0+. /dev and /3.4 is 3.4a0.  It might need clarifying
> in the PEP.
> ...
>> There's a slight mismatch with how we're doing it today because
>> "http://docs.python.org/3/"; shows 3.3.0 in the title even though it's
>> the in-progress 3.3.1.  The title should perhaps reflect that it's
>> post 3.3.0 (and similarly for the 2.7 and 3.2 pages).
>
> Well, that has always been the case, and it doesn't matter anyway, because
> generally there's nothing in 3.3.1, feature-wise, that won't have been in 
> 3.3.0.

One reason to change would be to avoid possible confusion created on
pages like this--

http://docs.python.org/3.3/whatsnew/3.2.html

where it says--

Author: Raymond Hettinger
Release: 3.3.0
Date: October 27, 2012

Would there be any disadvantage to changing the in-development titles
to read something like 3.3.0+, etc?

--Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: PEP for updating the URL layout on docs.python.org

[Georg Brandl]

Am 28.10.2012 13:19, schrieb Chris Jerdonek:
> On Sun, Oct 28, 2012 at 4:34 AM, Georg Brandl  wrote:
>> Am 28.10.2012 12:29, schrieb Chris Jerdonek:
>> ...
>> I understand "latest" to mean "latest stable plus bugfixes".
>> I.e., /3/ is 3.3.0+. /dev and /3.4 is 3.4a0.  It might need clarifying
>> in the PEP.
>> ...
>>> There's a slight mismatch with how we're doing it today because
>>> "http://docs.python.org/3/"; shows 3.3.0 in the title even though it's
>>> the in-progress 3.3.1.  The title should perhaps reflect that it's
>>> post 3.3.0 (and similarly for the 2.7 and 3.2 pages).
>>
>> Well, that has always been the case, and it doesn't matter anyway, because
>> generally there's nothing in 3.3.1, feature-wise, that won't have been in 
>> 3.3.0.
> 
> One reason to change would be to avoid possible confusion created on
> pages like this--
> 
> http://docs.python.org/3.3/whatsnew/3.2.html
> 
> where it says--
> 
> Author: Raymond Hettinger
> Release: 3.3.0
> Date: October 27, 2012

Well, that block is a little silly anyway.  I would just delete the
"Release" and "Date" lines.

> Would there be any disadvantage to changing the in-development titles
> to read something like 3.3.0+, etc?

I'm not sure it would lower any confusion, instead of creating more.
("What is that + anyway? Do I need another version?" etc.)

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: PEP for updating the URL layout on docs.python.org

[Antoine Pitrou]

On Sun, 28 Oct 2012 05:19:26 -0700
Chris Jerdonek  wrote:
> 
> One reason to change would be to avoid possible confusion created on
> pages like this--
> 
> http://docs.python.org/3.3/whatsnew/3.2.html
> 
> where it says--
> 
> Author: Raymond Hettinger
> Release: 3.3.0
> Date: October 27, 2012
> 
> Would there be any disadvantage to changing the in-development titles
> to read something like 3.3.0+, etc?

Well, first why does it mention 3.3.0 while it's the what's new for
3.2? That's totally confusing, this mention should simply be removed.
Also the date is not informative at all.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: PEP for updating the URL layout on docs.python.org

[Georg Brandl]

Am 28.10.2012 13:30, schrieb Antoine Pitrou:
> On Sun, 28 Oct 2012 05:19:26 -0700
> Chris Jerdonek  wrote:
>> 
>> One reason to change would be to avoid possible confusion created on
>> pages like this--
>> 
>> http://docs.python.org/3.3/whatsnew/3.2.html
>> 
>> where it says--
>> 
>> Author: Raymond Hettinger
>> Release: 3.3.0
>> Date: October 27, 2012
>> 
>> Would there be any disadvantage to changing the in-development titles
>> to read something like 3.3.0+, etc?
> 
> Well, first why does it mention 3.3.0 while it's the what's new for
> 3.2? That's totally confusing, this mention should simply be removed.
> Also the date is not informative at all.

Agreed, I've now removed them.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: PEP for updating the URL layout on docs.python.org

[Chris Jerdonek]

On Sun, Oct 28, 2012 at 5:39 AM, Georg Brandl  wrote:
> Am 28.10.2012 13:30, schrieb Antoine Pitrou:
>> Well, first why does it mention 3.3.0 while it's the what's new for
>> 3.2? That's totally confusing, this mention should simply be removed.
>> Also the date is not informative at all.
>
> Agreed, I've now removed them.

Thanks a lot.  Many of the index pages linked from the table of
contents also have uninformative release and date lines, e.g.

http://docs.python.org/3/library/index.html

but they use ":Release: |version|" (minor version without micro
version) instead of ":Release: |release|", so they're less likely to
be construed as an actual release date (but still uninformative).

--Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: PEP for updating the URL layout on docs.python.org

[Georg Brandl]

Am 28.10.2012 13:54, schrieb Chris Jerdonek:
> On Sun, Oct 28, 2012 at 5:39 AM, Georg Brandl  wrote:
>> Am 28.10.2012 13:30, schrieb Antoine Pitrou:
>>> Well, first why does it mention 3.3.0 while it's the what's new for
>>> 3.2? That's totally confusing, this mention should simply be removed.
>>> Also the date is not informative at all.
>>
>> Agreed, I've now removed them.
> 
> Thanks a lot.  Many of the index pages linked from the table of
> contents also have uninformative release and date lines, e.g.
> 
> http://docs.python.org/3/library/index.html
> 
> but they use ":Release: |version|" (minor version without micro
> version) instead of ":Release: |release|", so they're less likely to
> be construed as an actual release date (but still uninformative).

Right.  I think they are remnants from the LaTeX age; you can remove
them all if you want.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

[Hynek Schlawack]

Am 28.10.2012 um 12:11 schrieb Antoine Pitrou :

>> One word: profile.
>> 
>> Looking at stat counts alone rather than measuring the total time spent in
>> all types of system calls from strace and profiling is not really useful. ;)
> Agreed, but I can't seem to cope properly with gprof. Any suggestion?

http://oprofile.sourceforge.net/news/
http://valgrind.org/docs/manual/cl-manual.html

Are both useful.  gprof is virtually useless.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-ideas] docs.python.org

[Yury Selivanov]

On 2012-10-28, at 3:59 AM, Georg Brandl  wrote:

> Well, with the approval I've seen here, I have absolutely no problem
> with appointing myself PEP Czar and accepting the PEP :)

That's awesome!

-
Yury
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: PEP for updating the URL layout on docs.python.org

[Mark Lawrence]

On 28/10/2012 12:39, Georg Brandl wrote:

Am 28.10.2012 13:30, schrieb Antoine Pitrou:

On Sun, 28 Oct 2012 05:19:26 -0700
Chris Jerdonek  wrote:


One reason to change would be to avoid possible confusion created on
pages like this--

http://docs.python.org/3.3/whatsnew/3.2.html

where it says--

Author: Raymond Hettinger
Release: 3.3.0
Date: October 27, 2012

Would there be any disadvantage to changing the in-development titles
to read something like 3.3.0+, etc?


Well, first why does it mention 3.3.0 while it's the what's new for
3.2? That's totally confusing, this mention should simply be removed.
Also the date is not informative at all.


Agreed, I've now removed them.

Georg



Is it worth removing this as well, it's a couple of lines down

"See also PEP 392 - Python 3.2 Release Schedule" ?

--
Cheers.

Mark Lawrence.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: PEP for updating the URL layout on docs.python.org

[Georg Brandl]

Am 28.10.2012 17:23, schrieb Mark Lawrence:
> On 28/10/2012 12:39, Georg Brandl wrote:
>> Am 28.10.2012 13:30, schrieb Antoine Pitrou:
>>> On Sun, 28 Oct 2012 05:19:26 -0700
>>> Chris Jerdonek  wrote:

 One reason to change would be to avoid possible confusion created on
 pages like this--

 http://docs.python.org/3.3/whatsnew/3.2.html

 where it says--

 Author: Raymond Hettinger
 Release: 3.3.0
 Date: October 27, 2012

 Would there be any disadvantage to changing the in-development titles
 to read something like 3.3.0+, etc?
>>>
>>> Well, first why does it mention 3.3.0 while it's the what's new for
>>> 3.2? That's totally confusing, this mention should simply be removed.
>>> Also the date is not informative at all.
>>
>> Agreed, I've now removed them.
>>
>> Georg
>>
> 
> Is it worth removing this as well, it's a couple of lines down
> 
> "See also PEP 392 - Python 3.2 Release Schedule" ?

Why?  PEP 392 is not out of date, and for those who want to know when
exactly 3.2 and its minor versions were released, it is useful.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

[Antoine Pitrou]

On Sat, 27 Oct 2012 20:38:58 -0700
"Gregory P. Smith"  wrote:
> 
> Another thing to keep an eye out for within a startup profile:  how often
> does the gc collect?  our default gc collection thresholds haven't been
> tuned in ages afaik [or am i forgetting something] and I know of
> pathological cases at work where simply doing a gc.disable() before
> importing a bunch of modules (tons of generated protocol buffer code) and
> re-enabling it afterwards speeds up this application's startup way more
> significantly than seems healthy in 2.x... that could be related to the
> particulars of the protobuf module code though.

http://bugs.python.org/issue16351 shows us that the number of
collections at 3.4 startup is tiny:

$ ./python -Sc "import gc; print(gc.get_stats())"
[{'collections': 6, 'uncollectable': 0, 'collected': 0},
{'collections': 0, 'uncollectable': 0, 'collected': 0},
{'collections': 0, 'uncollectable': 0, 'collected': 0}]

$ ./python -c "import gc; print(gc.get_stats())"
[{'collected': 0, 'uncollectable': 0, 'collections': 12},
{'collected': 0, 'uncollectable': 0, 'collections': 1},
{'collected': 0, 'uncollectable': 0, 'collections': 0}]


Notably, there are no full collections.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] configure produces a non-working Makefile in some scenarios, due to ASDLGEN

[Vinay Sajip]

In some scenarios, configure produces a Makefile which fails because ASDLGEN
doesn't point to a working Python. In particular, it seems to assume that if
there is an executable called e.g. "python3.4" on the path, then that will be a
system Python.

In my perhaps unusual but IMO perfectly valid setup, I have various Python repos
set up like so:

$HOME/projects/python
 |
 +- default
 |
 +- 3.3
 |
 + and so on for 3.2, 3.1, 2.7

In order to facilitate testing some script against multiple Python versions, I
have shell scripts in $HOME/bin named python3.4, python3.3 etc. which just run
the programs in the relevant directories in $HOME/projects/python/. (I know I
can do this using aliases etc., but I think that's beside the point.)

When I run configure in the repo for the default branch, it appears to look for
a Python on the path named python3.4, finds one in $HOME/bin, and thus generates
an ASDLGEN value of "python3.4". If I happen to have a built Python in the
default repo, then the script in $HOME/bin will successfully run that, and all
appears well; but if I clean the default repo and re-run make, it fails at the
ASDLGEN step, because the $HOME/bin/python3.4 script fails, due to not being
able to invoke $HOME/projects/python/default/python.

Is this a bug in configure, or is my configuration regarded as too perverse to
support?

Regards,

Vinay Sajip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: PEP for updating the URL layout on docs.python.org

[Chris Jerdonek]

On Sun, Oct 28, 2012 at 6:05 AM, Georg Brandl  wrote:
> Am 28.10.2012 13:54, schrieb Chris Jerdonek:
>> On Sun, Oct 28, 2012 at 5:39 AM, Georg Brandl  wrote:
>>> Am 28.10.2012 13:30, schrieb Antoine Pitrou:
 Well, first why does it mention 3.3.0 while it's the what's new for
 3.2? That's totally confusing, this mention should simply be removed.
 Also the date is not informative at all.
>>>
>>> Agreed, I've now removed them.
>>
>> Thanks a lot.  Many of the index pages linked from the table of
>> contents also have uninformative release and date lines, e.g.
>>
>> http://docs.python.org/3/library/index.html
>>
>> but they use ":Release: |version|" (minor version without micro
>> version) instead of ":Release: |release|", so they're less likely to
>> be construed as an actual release date (but still uninformative).
>
> Right.  I think they are remnants from the LaTeX age; you can remove
> them all if you want.

Great, I just removed them.

--Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] configure produces a non-working Makefile in some scenarios, due to ASDLGEN

[Antoine Pitrou]

On Sun, 28 Oct 2012 18:24:36 + (UTC)
Vinay Sajip  wrote:
> In some scenarios, configure produces a Makefile which fails because ASDLGEN
> doesn't point to a working Python. In particular, it seems to assume that if
> there is an executable called e.g. "python3.4" on the path, then that will be 
> a
> system Python.
> 
> In my perhaps unusual but IMO perfectly valid setup, I have various Python 
> repos
> set up like so:
> 
> $HOME/projects/python
>  |
>  +- default
>  |
>  +- 3.3
>  |
>  + and so on for 3.2, 3.1, 2.7
> 
> In order to facilitate testing some script against multiple Python versions, I
> have shell scripts in $HOME/bin named python3.4, python3.3 etc. which just run
> the programs in the relevant directories in $HOME/projects/python/. (I know I
> can do this using aliases etc., but I think that's beside the point.)
> 
> When I run configure in the repo for the default branch, it appears to look 
> for
> a Python on the path named python3.4, finds one in $HOME/bin, and thus 
> generates
> an ASDLGEN value of "python3.4". If I happen to have a built Python in the
> default repo, then the script in $HOME/bin will successfully run that, and all
> appears well; but if I clean the default repo and re-run make, it fails at the
> ASDLGEN step, because the $HOME/bin/python3.4 script fails, due to not being
> able to invoke $HOME/projects/python/default/python.
> 
> Is this a bug in configure, or is my configuration regarded as too perverse to
> support?

The latter IMO :)

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] accept the wheel PEPs 425, 426, 427

[Daniel Holth]

I think Metadata 1.3 is done. Who would like to czar?
On Oct 22, 2012 12:53 PM, "Daniel Holth"  wrote:

> http://hg.python.org/peps/rev/50e8ea1a17a0
>
> Based on the other "required" field's absence in the wild, only
> "Metadata-Version", "Name", "Version", and "Summary" are required.
> Hopefully a clearer explanation of 0, 1, or many occurrences of each
> field.
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

[Tim Delaney]

On 28 October 2012 18:22, Stefan Behnel  wrote:

> How much of an
>
>> effect would it have on startup times and these benchmarks if
>> Cython-compiled extensions were used?
>>
>
> Depends on what and how much code you use. If you compile everything into
> one big module that "imports" all of the stdlib when it gets loaded, you'd
> likely loose a lot of time because it would take a while to initialise all
> that useless code on startup. If you keep it separate, it would likely be a
> lot faster because you avoid the interpreter for most of the module startup.
>

I was specifically thinking in terms of the tests Brett ran (that was the
full set on speed.python.org, wasn't it?), and having each stdlib module be
its own extension i.e. no big import module. A literal 1:1 replacement
where possible.


> I'm thinking here of elimination of .pyc interpretation and execution (stat
>
>> calls would be similar, probably slightly higher).
>>
>
> CPython checks for .so files before looking for .py files and imports are
> absolute by default in Py3, so there should be a slight reduction in stat
> calls. The net result then obviously also depends on how fast your shared
> library loader and linker is, etc., but I doubt that that path is any
> slower than loading and running a .pyc file.
>

D'oh. I knew that and still got it backwards.


> To be clear - I'm *not* suggesting Cython become part of the required build
>> toolchain. But *if* the Cython-compiled extensions prove to be
>> significantly faster I'm thinking maybe it could become a semi-supported
>> option (e.g. a HOWTO with the caveat "it worked on this particular
>> system").
>>
>
> Sounds reasonable.


I think a stdlib compile script + pre-packaged hints for the 3.3 release
would likely help both 3.3 and Cython acceptance.

Putting aside my development interest and looking at it purely from the PoV
of a Python *user*, I'd really like to see Cython on
speed.python.orgeventually (in two modes - one without hints as a
baseline and one with
hints). Of course the ideal situation would be to have every implementation
of Python 3.3 that is capable of running on the hardware contributing
numbers e.g. if/when Jython achieves 3.3 compatibility I'd love to see
numbers for it.

Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

[Catalin Iacob]

On Sat, Oct 27, 2012 at 11:07 PM, Paul Moore  wrote:
> Interestingly, I just did a quick test of this: This is on my Windows
> 7 PC, running under Powershell.

snip

> Looks like the normal configuration is over twice as fast as the zipped one...

This result is influenced by zipimport fseek-ing for every file in the
imported zip and fseek flushing buffers in Microsoft's CRT
implementation. There's a patch which avoids the seek in
http://bugs.python.org/issue8745. Reviews welcome!

With that patch the time taken to import is half of the current state
of things so according to your test that would make zipped and non
zipped configurations roughly equally fast.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] accept the wheel PEPs 425, 426, 427

[Daniel Holth]

Now with an implementation at the end and possibly better wording for
the required fields. I think it's feature complete.


PEP: 426
Title: Metadata for Python Software Packages 1.3
Version: $Revision$
Last-Modified: $Date$
Author: Daniel Holth 
Discussions-To: Distutils SIG
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 30 Aug 2012


Abstract


This PEP describes a mechanism for adding metadata to Python distributions.
It includes specifics of the field names, and their semantics and
usage.

This document specifies version 1.3 of the metadata format.
Version 1.0 is specified in PEP 241.
Version 1.1 is specified in PEP 314.
Version 1.2 is specified in PEP 345.

Version 1.3 of the metadata format adds fields designed to make
third-party packaging of Python Software easier and defines a
formal extension mechanism.  The fields are "Setup-Requires-Dist"
"Provides-Extra", and "Extension".  This version also adds the `extra`
variable to the `environment markers` specification and allows the
description to be placed into a payload section.

Metadata Files
==

The syntax defined in this PEP is for use with Python distribution
metadata files. The file format is a simple UTF-8 encoded Key: value
format with no maximum line length, followed by a blank line and an
arbitrary payload.  It is parseable by the ``email`` module with an
appropriate ``email.policy.Policy()``.

When ``metadata`` is a Unicode string,
```email.parser.Parser().parsestr(metadata)`` is a serviceable parser.

There are two standard locations for these metadata files:

* the ``PKG-INFO`` file included in the base directory of Python
  source distribution archives (as created by the distutils ``sdist``
  command)
* the ``.dist-info/METADATA`` files in a Python installation database, as
  described in PEP 376.

Other tools involved in Python distribution may also use this format.

Encoding


Metadata 1.3 files are UTF-8 with the restriction that keys must be
ASCII. Parser implementations should be aware that older versions of
the Metadata specification do not specify an encoding.

Fields
==

This section specifies the names and semantics of each of the
supported metadata fields.

In a single Metadata 1.3 file, fields marked with "(optional)" may occur
0 or 1 times.  Fields marked with "(multiple use)" may be specified
0, 1 or more times.  Only "Metadata-Version", "Name", "Version", and
"Summary" must appear exactly once.  The fields may appear in any order
within the file.

Metadata-Version


Version of the file format; "1.3" is the only legal value.

Example::

Metadata-Version: 1.3


Name


The name of the distribution.

Example::

Name: BeagleVote


Version
:::

A string containing the distribution's version number.  This
field  must be in the format specified in PEP 386.

Example::

Version: 1.0a2


Summary
:::

A one-line summary of what the distribution does.

Example::

Summary: A module for collecting votes from beagles.


Platform (multiple use)
:::

A Platform specification describing an operating system supported by
the distribution which is not listed in the "Operating System" Trove
classifiers.
See "Classifier" below.

Examples::

Platform: ObscureUnix
Platform: RareDOS


Supported-Platform (multiple use)
:

Binary distributions containing a metadata file will use the
Supported-Platform field in their metadata to specify the OS and
CPU for which the binary distribution was compiled.  The semantics of
the Supported-Platform field are not specified in this PEP.

Example::

Supported-Platform: RedHat 7.2
Supported-Platform: i386-win32-2791


Description (optional, deprecated)
::

A longer description of the distribution that can run to several
paragraphs.  Software that deals with metadata should not assume
any maximum size for this field.

The contents of this field can be written using reStructuredText
markup [1]_.  For programs that work with the metadata, supporting
markup is optional; programs can also display the contents of the
field as-is.  This means that authors should be conservative in
the markup they use.

Since a line separator immediately followed by another line separator
indicates the end of the headers section, any line separators in the
description must be suffixed by whitespace to indicate continuation.

Since Metadata 1.3 the recommended place for the description is in the
payload section of the document, after the last header.  The description
does not need to be reformatted when it is included in the payload.


Keywords (optional)
:::

A list of additional keywords to be used to assist searching
for the distribution in a larger catalog.

Example::

Keywords: dog puppy voting election


Home-page (optional)


A string containing the URL for the distribution's home page.

Example::

   

Re: [Python-Dev] configure produces a non-working Makefile in some scenarios, due to ASDLGEN

[Cameron Simpson]

On 28Oct2012 18:24, Vinay Sajip  wrote:
| In some scenarios, configure produces a Makefile which fails because ASDLGEN
| doesn't point to a working Python. In particular, it seems to assume that if
| there is an executable called e.g. "python3.4" on the path, then that will be 
a
| system Python.

Or at least a valid python. Given that python installs create a pythonA.B
executable/symlink I would call that a reasonable assumption.

If I invoke the command "python2.7", I expect to get a python 2.7.x
instance. Indeed, I have scripts that expect that (eg my py26+ script
which looks for a sufficiently new python for particular tasks).

| In my perhaps unusual but IMO perfectly valid setup, I have various Python 
repos
| set up like so:
| 
| $HOME/projects/python
|  |
|  +- default
|  |
|  +- 3.3
|  |
|  + and so on for 3.2, 3.1, 2.7

That's sane.

| In order to facilitate testing some script against multiple Python versions, I
| have shell scripts in $HOME/bin named python3.4, python3.3 etc. which just run
| the programs in the relevant directories in $HOME/projects/python/. (I know I
| can do this using aliases etc., but I think that's beside the point.)

That is not sane. And aliases aren't quite beside the point, though
nearly so. At least aliases aren't used by shell scripts on the whole,
which executables in the $PATH are.

A python install includes a pythonA.B executable. You're providing
"pythonA.B" which is _not_ a python executable!

If you had a shell script in your ~/bin called "ls" that ran "rm", would
you consider it sensible? I wouldn't.

I'm sure you're well aware of the newbie UNIX mistake of calling a test
script "test", too:-) Same issue, really.

| When I run configure in the repo for the default branch, it appears to look 
for
| a Python on the path named python3.4, finds one in $HOME/bin, and thus 
generates
| an ASDLGEN value of "python3.4". If I happen to have a built Python in the
| default repo, then the script in $HOME/bin will successfully run that, and all
| appears well; but if I clean the default repo and re-run make, it fails at the
| ASDLGEN step, because the $HOME/bin/python3.4 script fails, due to not being
| able to invoke $HOME/projects/python/default/python.
| 
| Is this a bug in configure, or is my configuration regarded as too perverse to
| support?

I agree with Antoine; it is slightly perverse. But entirely because of the
executable names you've chosen.

When I run configure I take care to _trash_ my $PATH. Well, to make it
more conventional. Configure relies heavily on $PATH (and a host of
other ill-documented variables, like $ARCH or $CPU, I forget now; I have
wrapper scripts to toss tis stuff and hand me a fresh shell for exactly
this issue).

I have long found it useful to craft my environment before using
configure. Specificly, the $PATH _must_ find the expected executable
names appropriately. I your case it will not.

I would have test scripts do something of this flavour:

  PATH={your-test-area-here}/bin:/usr/bin:/bin:/usr/local/bin
  export PATH

to ensure that configure finds what it expects.

I would also rename your ~/bin/python3.4 et al scripts to something more
descriptive; I have over the past several years been naming my own
scripts progressively more verbosely. Maybe "test-python-3.4" and so
forth. And make some convenience aliases (_not_ conflicting with
"standard" names like "python3.4", maybe "testpy34" or something equally
short). And having made those convenience aliases, possibly even move
the test wrapper scripts our of my ~/bin depending on how widely that
get used by other higher level scripts.

Hoping this is more helpful than I've probably made it sound,
-- 
Cameron Simpson 

Nothing is impossible for the man who doesn't have to do it.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] configure produces a non-working Makefile in some scenarios, due to ASDLGEN

[Ned Deily]

In article <20121028194043.09415...@pitrou.net>,
 Antoine Pitrou  wrote:

> On Sun, 28 Oct 2012 18:24:36 + (UTC)
> Vinay Sajip  wrote:
> > In some scenarios, configure produces a Makefile which fails because 
> > ASDLGEN
> > doesn't point to a working Python. In particular, it seems to assume that 
> > if
> > there is an executable called e.g. "python3.4" on the path, then that will 
> > be a
> > system Python.
> > 
> > In my perhaps unusual but IMO perfectly valid setup, I have various Python 
> > repos
> > set up like so:
> > 
> > $HOME/projects/python
> >  |
> >  +- default
> >  |
> >  +- 3.3
> >  |
> >  + and so on for 3.2, 3.1, 2.7
> > 
> > In order to facilitate testing some script against multiple Python 
> > versions, I
> > have shell scripts in $HOME/bin named python3.4, python3.3 etc. which just 
> > run
> > the programs in the relevant directories in $HOME/projects/python/. (I know 
> > I
> > can do this using aliases etc., but I think that's beside the point.)
> > 
> > When I run configure in the repo for the default branch, it appears to look 
> > for
> > a Python on the path named python3.4, finds one in $HOME/bin, and thus 
> > generates
> > an ASDLGEN value of "python3.4". If I happen to have a built Python in the
> > default repo, then the script in $HOME/bin will successfully run that, and 
> > all
> > appears well; but if I clean the default repo and re-run make, it fails at 
> > the
> > ASDLGEN step, because the $HOME/bin/python3.4 script fails, due to not 
> > being
> > able to invoke $HOME/projects/python/default/python.
> > 
> > Is this a bug in configure, or is my configuration regarded as too perverse 
> > to
> > support?
> 
> The latter IMO :)

Not at all, IMO :)

This behavior is a change recently introduced by the changesets 
associated with http://bugs.python.org/issue16262.  Previously, the 
first `python` on $PATH was used if asdl_c.py needed to be run in the 
Makefile.  You now have the opportunity to override the behavior at 
./configure time by using the PYTHON variable to specify the path to the 
Python executable you want to use for the asdl_c.py step, as in:

   ./configure ... PYTHON=/usr/bin/python2.7

-- 
 Ned Deily,
 n...@acm.org

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Acceptance of PEPs

[Brian Curtin]

I just found out that PEP 430 came up again and was approved, but only
because of another website. After that I looked back through my email
only to find mention via python-checkins. Aren't PEPs typically acted
on here on python-dev?

I mention this because I was writing up a blog.python.org post about
the (somewhat recent) Sphinx theme change and the change to add a
version dropdown which was pushed yesterday. I was about to wrap it up
and schedule it for tomorrow when I found out about 430, which I'm now
including.


note: I have no problems with that PEP actually being approved. I've
wanted that change for 2 years.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Acceptance of PEPs

[Chris Jerdonek]

On Sun, Oct 28, 2012 at 9:05 PM, Brian Curtin  wrote:
> I just found out that PEP 430 came up again and was approved, but only
> because of another website. After that I looked back through my email
> only to find mention via python-checkins. Aren't PEPs typically acted
> on here on python-dev?

FWIW, the following e-mail was cross-posted to python-dev:

http://mail.python.org/pipermail/python-ideas/2012-October/017494.html

The message doesn't seem to show up in the python-dev archives though:

http://mail.python.org/pipermail/python-dev/2012-October/thread.html

Perhaps this is because python-dev was the "CC" rather than the "To"
(which was python-ideas).  Here is another message that does show up
in the python-dev archives (and which quotes the acceptance):

http://mail.python.org/pipermail/python-dev/2012-October/122458.html

--Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Acceptance of PEPs

[Georg Brandl]

Am 29.10.2012 05:05, schrieb Brian Curtin:
> I just found out that PEP 430 came up again and was approved, but only
> because of another website. After that I looked back through my email
> only to find mention via python-checkins. Aren't PEPs typically acted
> on here on python-dev?

Yes, that's why I cross-posted the acceptance email here.

> I mention this because I was writing up a blog.python.org post about
> the (somewhat recent) Sphinx theme change and the change to add a
> version dropdown which was pushed yesterday. I was about to wrap it up
> and schedule it for tomorrow when I found out about 430, which I'm now
> including.
> 
> 
> note: I have no problems with that PEP actually being approved. I've
> wanted that change for 2 years.

For most PEPs, a longer contemplation and discussion period is of course
required. But in this case I don't think a PEP would have been required
anyway, and it matched more or less what was already discussed this time
*and* the last time this came up (at which time I didn't act on it).  So
it seemed the best course of action to do it right now.

Georg



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: PEP for updating the URL layout on docs.python.org

[Chris Jerdonek]

On Sat, Oct 27, 2012 at 7:36 AM, nick.coghlan
 wrote:
> http://hg.python.org/peps/rev/c7ba002ca91d
> changeset:   4568:c7ba002ca91d
> user:Nick Coghlan 
> date:Sun Oct 28 00:36:36 2012 +1000
> summary:
>   PEP for updating the URL layout on docs.python.org
> ...
> +Implementation
> +==
> +
> +The URLs on docs.python.org are controlled by the python.org infrastructure
> +team rather than through the CPython source repo, so acceptance and
> +implementation of the ideas in this PEP will be up to the team.

Related to this, just checking to see if anyone is taking
responsibility for following up with http://www.python.org.  I imagine
they have several links that may no longer point to the correct
version (e.g. the "Documentation" link under "Quick Links (2.7.3)" in
the left column of the home page now results in
http://docs.python.org/3/, and similarly for 2.x on
http://www.python.org/doc/ ).

--Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Acceptance of PEPs

[Barry Warsaw]

On Oct 28, 2012, at 11:05 PM, Brian Curtin wrote:

>I just found out that PEP 430 came up again and was approved, but only
>because of another website. After that I looked back through my email
>only to find mention via python-checkins. Aren't PEPs typically acted
>on here on python-dev?
>
>I mention this because I was writing up a blog.python.org post about
>the (somewhat recent) Sphinx theme change and the change to add a
>version dropdown which was pushed yesterday. I was about to wrap it up
>and schedule it for tomorrow when I found out about 430, which I'm now
>including.

PEP 1 states that proposals must be sent to python-dev after discussion on
python-ideas.  As for acceptance, PEP 1 says:

Once the authors have completed a PEP, they may request a review for
style and consistency from the PEP editors.  However, the content and
final acceptance of the PEP must be requested of the BDFL, usually via
an email to the python-dev mailing list.

...

When a PEP is Accepted, Rejected or Withdrawn, the PEP should be updated
accordingly. In addition to updating the status field, at the very least
the Resolution header should be added with a link to the relevant post
in the python-dev mailing list archives.

So yes, python-dev needs to be the place where PEPs are discussed and
accepted.

Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com