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 menti
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
>
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 w
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?
FW
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 a
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 t
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.
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: Sta
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 fo
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 s
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
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
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 to
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 set
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 ca
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 thi
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--
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
h
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 sugge
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.
>>>
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
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: Raymo
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
>
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
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 ho
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
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:
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
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
>
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
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
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. An
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
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
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 inser
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:a8052ad
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
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/pyth
38 matches
Mail list logo
