On Fri, Aug 12, 2011 at 8:21 AM, Terry Reedy wrote:
> On 8/11/2011 3:31 PM, Victor Stinner wrote:
>> Ok, most people prefer this option. Should I modify the PEP to "move"
>> this option has the first/main proposition (move my proposition as an
>> alternative?), or can the PEP be validated in the c
On Fri, Aug 12, 2011 at 1:12 AM, Éric Araujo wrote:
> I’m sorry if my opinion on that main point was lost among remarks on
> details. To rephrase one part of my reply: Right now, the de facto
> standard is that shebangs can use python to mean python2 and python3 to
> mean python3. Adding python2
On Fri, Aug 12, 2011 at 4:30 AM, P.J. Eby wrote:
> At 04:39 PM 8/11/2011 +0200, Éric Araujo wrote:
>> > The resulting list (whether empty or not) is then stored in a
>> > ``sys.virtual_package_paths`` dictionary, keyed by module name.
>> This was probably said on import-sig, but here I go: yet an
On 8/11/2011 3:31 PM, Victor Stinner wrote:
Le 29/07/2011 19:01, Guido van Rossum a écrit :
I will add your alternative to the PEP (except if you would like to do
that yourself?). If I understood correctly, you propose to:
* rename codecs.open() to codecs.open_stream()
* change codecs.open() to
On 8/11/2011 10:36 AM, Éric Araujo wrote:
It would be interesting to have feedback from people who lived the
transition to Python 2.
There was no comparable transition. Python 2.0 was basically 1.6 renamed
for a different distributor. I regard Python 2.2, which introduced
new-style, as the b
Le 29/07/2011 19:01, Guido van Rossum a écrit :
I will add your alternative to the PEP (except if you would like to do
that yourself?). If I understood correctly, you propose to:
* rename codecs.open() to codecs.open_stream()
* change codecs.open() to reuse open() (and so io.TextIOWrapper)
Den 09.08.2011 11:33, skrev Марк Коренберг:
Probably I want to re-invent a bicycle. I want developers to say me
why we can not remove GIL in that way:
1. Remove GIL completely with all current logick.
2. Add it's own RW-locking to all mutable objects (like list or dict)
3. Add RW-locks to every
On Thu, 11 Aug 2011 17:12:22 +0200, =?UTF-8?B?w4lyaWMgQXJhdWpv?=
wrote:
> Iâm sorry if my opinion on that main point was lost among remarks on
> details. To rephrase one part of my reply: Right now, the de facto
> standard is that shebangs can use python to mean python2 and python3 to
> mean p
At 04:39 PM 8/11/2011 +0200, Ãric Araujo wrote:
Hi,
I've read PEP 402 and would like to offer comments.
Thanks.
Minor: I would reserve "packaging" for
packaging/distribution/installation/deployment matters, not Python
modules. I suggest "Python package semantics".
Changing to "Python pac
Am 11.08.2011 17:01, schrieb Merwok:
> Le 11/08/2011 16:47, Sandro Tosi a écrit :
>> Is there a reason we can't use the same sphinx role in 2.7 too? And
>> also the same sphinx (thus sphinxext) versions on 2.7 and 3.x? that
>> would probably help in keeping the diffs on the documentation smaller.
>
On Thu, 11 Aug 2011 11:39:52 -0400
Barry Warsaw wrote:
> On Aug 11, 2011, at 04:39 PM, Éric Araujo wrote:
>
> >> * XXX what is the __file__ of a "pure virtual" package? ``None``?
> >> Some arbitrary string? The path of the first directory with a
> >> trailing separator? No matter what we
On Aug 11, 2011, at 11:39 AM, Barry Warsaw wrote:
> On Aug 11, 2011, at 04:39 PM, Éric Araujo wrote:
>
>>> * XXX what is the __file__ of a "pure virtual" package? ``None``?
>>> Some arbitrary string? The path of the first directory with a
>>> trailing separator? No matter what we put, *some*
On Aug 11, 2011, at 04:39 PM, Éric Araujo wrote:
>> * XXX what is the __file__ of a "pure virtual" package? ``None``?
>> Some arbitrary string? The path of the first directory with a
>> trailing separator? No matter what we put, *some* code is
>> going to break, but the last choice might
Hi Devid,
> I think you missed the point of the PEP. The point is to create a new,
> python-dev-blessed standard that the distros will follow. The primary
> goal is so that a script can specify python2 or python3 in the #!
> line and expect that to work on all compliant linux systems, which we
>
I think you missed the point of the PEP. The point is to create a new,
python-dev-blessed standard that the distros will follow. The primary
goal is so that a script can specify python2 or python3 in the #!
line and expect that to work on all compliant linux systems, which we
hope will be all of
Le 11/08/2011 16:47, Sandro Tosi a écrit :
> Is there a reason we can't use the same sphinx role in 2.7 too? And
> also the same sphinx (thus sphinxext) versions on 2.7 and 3.x? that
> would probably help in keeping the diffs on the documentation smaller.
Even though the pyspecific module is wholl
On Thu, Aug 11, 2011 at 16:33, Éric Araujo wrote:
> Hi,
>
>> IIRC the reason why we don't do it on 2.x is because we don't have the
>> 'source' directive available in Sphinx and therefore we would have to
>> update all the links manually to link to h.p.o instead of s.p.o.
>
> In 3.2 and higher, th
On Thu, Aug 11, 2011 at 00:26, Georg Brandl wrote:
> Am 11.08.2011 03:34, schrieb brian.curtin:
> > http://hg.python.org/cpython/rev/3a6782f2a4a8
> > changeset: 71811:3a6782f2a4a8
> > user:Brian Curtin
> > date:Wed Aug 10 20:32:10 2011 -0500
> > summary:
> > News item for #12
Hi,
I’ve read PEP 402 and would like to offer comments.
I know a bit about the import system, but not down to the nitty-gritty
details of PEP 302 and __path__ computations and all this fun stuff (by
which I mean, not fun at all). As such, I can’t find nasty issues in
dark corners, but I can offe
Hi,
I’ve read the latest version of this PEP, as updated by Nick Coghlan in
the Mercurial repo on July, 20th. Excuse me if I repeat old arguments,
I did not reread all the threads.
In summary, I don’t think the PEP is useful right now, nor that it will
set a good practice for the future.
> * Un
Hi,
> IIRC the reason why we don't do it on 2.x is because we don't have the
> 'source' directive available in Sphinx and therefore we would have to
> update all the links manually to link to h.p.o instead of s.p.o.
In 3.2 and higher, there is a custom source role in
Doc/tools/sphinxext/pyspeci
On Thu, Aug 11, 2011 at 10:56 AM, Nick Coghlan wrote:
> On Thu, Aug 11, 2011 at 5:07 PM, Antoine Pitrou
> wrote:
> > Le Thu, 11 Aug 2011 09:03:35 +1000,
> > Nick Coghlan a écrit :
> >> On Thu, Aug 11, 2011 at 4:55 AM, Brian Curtin
> >> wrote:
> >> > Now that we have concurrent.futures, is ther
On Thu, Aug 11, 2011 at 5:07 PM, Antoine Pitrou wrote:
> Le Thu, 11 Aug 2011 09:03:35 +1000,
> Nick Coghlan a écrit :
>> On Thu, Aug 11, 2011 at 4:55 AM, Brian Curtin
>> wrote:
>> > Now that we have concurrent.futures, is there any plan for
>> > multiprocessing to follow suit? PEP 3148 mentions
Le Thu, 11 Aug 2011 09:03:35 +1000,
Nick Coghlan a écrit :
> On Thu, Aug 11, 2011 at 4:55 AM, Brian Curtin
> wrote:
> > Now that we have concurrent.futures, is there any plan for
> > multiprocessing to follow suit? PEP 3148 mentions a hope to add or move
> > things in the future [0], which would
Le Thu, 11 Aug 2011 03:34:37 +0200,
brian.curtin a écrit :
> http://hg.python.org/cpython/rev/77a65b078852
> changeset: 71809:77a65b078852
> parent: 71803:1b4fae183da3
> user:Brian Curtin
> date:Wed Aug 10 20:05:21 2011 -0500
> summary:
> Add Py_RETURN_NOTIMPLEMENTED macr
25 matches
Mail list logo
