> I saw a talk today in which the presenter was talking about "guaranteed
> transfer of ownership" enforced by the language runtime. Essentially, it
> was a technique to allow a data structure to be passed from one thread
> to another, with a guarantee that there would be no heap pointers under
> c
Hi Martin,
Stefan Behnel wrote:
>> Martin v. Löwis wrote:
>>> I just finished a PEP 3121 implementation
>
> what's the migration path to write portable code, then?
Looking through your complete commit, I realised that it's actually not that
hard to work around the API changes by basically provid
Guido van Rossum wrote:
On Wed, Jun 11, 2008 at 4:35 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
So I had planned to do a bunch of work last night looking at the release
blocker issues, but nature intervened. A bunch of severe thunderstorms
knock out my 'net access until this morning.
I'll try
That's odd - I've been doing all of the mp work on osx 10.5.3 - I'll
run the units in a loop today to see if I can catch it.
-Jesse
On Jun 12, 2008, at 1:00 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Much thanks to Benjamin Peterson and Alexandr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 12, 2008, at 7:08 AM, Jesse Noller wrote:
That's odd - I've been doing all of the mp work on osx 10.5.3 - I'll
run the units in a loop today to see if I can catch it.
-Jesse
Thanks. It's definitely reproducible on both my Leopard boxes.
[Barry]
>>> http://bugs.python.org/issue643841
[Guido]
>> I've added a comment. Let me know if anything I said is unclear.
On Thu, Jun 12, 2008 at 3:35 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The bugtracker seems to be offline atm - I'll reply there once I can get to
> it again (as well as
Guido van Rossum wrote:
[Barry]
http://bugs.python.org/issue643841
[Guido]
I've added a comment. Let me know if anything I said is unclear.
On Thu, Jun 12, 2008 at 3:35 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
The bugtracker seems to be offline atm - I'll reply there once I can get to
i
Michael Foord wrote:
Guido van Rossum wrote:
Whether they'll care about this issue of course depends on whether
they need overloaded operators and other special delegations to be
delegated transparently. We'll have to see how important this is.
New-style classes have been around and recommended
M.-A. Lemburg wrote:
On 2008-06-11 17:15, Walter Dörwald wrote:
M.-A. Lemburg wrote:
On 2008-06-11 13:35, Barry Warsaw wrote:
So I had planned to do a bunch of work last night looking at the
release blocker issues, but nature intervened. A bunch of severe
thunderstorms knock out my 'net acce
Hello all,
> Whether they'll care about this issue of course depends on whether
> they need overloaded operators and other special delegations to be
> delegated transparently.
Perhaps it may happen more implicitly than people think. Especially
for methods like __bool__, __str__, __iter__...
Afte
On 2008-06-12 16:59, Walter Dörwald wrote:
M.-A. Lemburg wrote:
.transform() and .untransform() use the codecs to apply same-type
conversions. They do apply type checks to make sure that the
codec does indeed return the same type.
E.g. text.transform('xml-escape') or data.transform('base64').
[-python-dev]
[Guido]
>> Whether they'll care about this issue of course depends on whether
>> they need overloaded operators and other special delegations to be
>> delegated transparently. We'll have to see how important this is.
>> New-style classes have been around and recommended for a long ti
On 6/12/08, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> documentation patch for the language reference ...
> following categories:
...
> 2. Method lookup MAY bypass __getattribute__, shadowing the attribute in
> the instance dictionary MAY have ill effects. (slots such as __enter__ and
> __exit__
Nick Coghlan schrieb:
2. Method lookup MAY bypass __getattribute__, shadowing the attribute in
the instance dictionary MAY have ill effects. (slots such as __enter__
and __exit__ that are looked up via normal attribute lookup in CPython
will fit into this category)
I would argue that the __e
> Was it necessary to remove Py_InitModule4() for this change? We use that in
> Cython, so this breaks building extension module in current Py3.
Yes: the new module API takes a number of additional function pointers,
which can't be passed in through Py_InitModule4.
While the change indeed systema
> So, next question: what's the migration path to write portable code, then? Up
> to this change, we supported every Python version starting from 2.3, including
> 3.0alpha5, and it would be nice to continue to do so with 3.0 final.
I would split out the main body of the initialization into a separ
> Just to mention it, I actually like the new API a lot, and we'll build upon
> that to provide better module cleanup support in later versions. That's
> something that we were missing for a while already.
Thanks. That actually needs proof in reality, as all core modules
currently only have the mi
Martin v. Löwis wrote:
However, _sre relied on the module already being in
sys.modules, as it runs Python code in the init function that already
imports the module being initialized.
This issue also potentially affects all Pyrex and Cython
generated modules, which must be free to execute
It's water under the bridge now, but IMO it was too rash to *remove*
the old threading API from Py3k, and doubly rash to do so one day
before the beta release. Running up to a release (whether alpha, beta
or final) we should practice extra restraint, not rush to get things
in right before the deadl
Guido van Rossum schrieb:
It's water under the bridge now, but IMO it was too rash to *remove*
the old threading API from Py3k, and doubly rash to do so one day
before the beta release. Running up to a release (whether alpha, beta
or final) we should practice extra restraint, not rush to get thin
20 matches
Mail list logo
