Stefan Behnel, 02.03.2010 10:06:
I just noticed that the xml.etree.ElementTree.tostring() function in Py3.2
returns a str object by default, unless an encoding is specified. This is a
backwards incompatible change compared to ET 1.2. For one, it breaks tons
of tests in lxml's compatibility test s
2010/3/2 Antoine Pitrou :
> Le Tue, 2 Mar 2010 17:28:11 -0800,
> Raymond Hettinger a écrit :
>> -1 for several reasons.
>>
>> 1) We've advertised -3 as part of TheOneTrueWay(tm). It's a core
>> part of our transition story, so we should keep that as
>> clean/consistent as possible. Deprecating t
Le Tue, 2 Mar 2010 17:28:11 -0800,
Raymond Hettinger a écrit :
> -1 for several reasons.
>
> 1) We've advertised -3 as part of TheOneTrueWay(tm). It's a core
> part of our transition story, so we should keep that as
> clean/consistent as possible. Deprecating the -3 switch seems like
> shooti
Le Tue, 02 Mar 2010 22:54:25 +0100,
"Martin v. Löwis" a écrit :
>
> > This is annoying since there were Mercurial mirrors there
> > ( at http://code.python.org/hg ). Until we make the official switch,
> > these mirrors are still useful.
>
> Do you know who is in charge of creating the site? I co
Hello everyone,
The source tarballs and Windows installer for Python 2.6.5 release candidate 1
are now available:
http://www.python.org/download/releases/2.6.5/
Please download them, install them, and try to use them with your favorite
projects and environments. If no regressions are found, we
I don't think this will help you solve your problem, but one thing
we've done in unladen swallow is to hack PyType_Modified to invalidate
our own descriptor caches. We may eventually want to extend that into
a callback interface, but it probably will never be considered an API
that outside code sh
2010/3/2 Daniel Stutzbach :
> In CPython, is it safe to cache function pointers that are in type objects?
>
> For example, if I know that some_type->tp_richcompare is non-NULL, and I
> call it (which may execute arbitrary user code), can I assume that
> some_type->tp_richcompare is still non-NULL?
In CPython, is it safe to cache function pointers that are in type objects?
For example, if I know that some_type->tp_richcompare is non-NULL, and I
call it (which may execute arbitrary user code), can I assume that
some_type->tp_richcompare is still non-NULL?
--
Daniel Stutzbach, Ph.D.
President
>
> On Tue, Mar 2, 2010 at 15:55, Florent Xicluna
> wrote:
> Hello,
>
> I would like to open a discussion on the meaning of deprecation warnings in
> 2.7.
> I assume, but I may be wrong, that 2.7 will be the last version in the 2.x
> branch. With this assumption, we should not find many thin
On Tue, Mar 2, 2010 at 15:55, Florent Xicluna wrote:
> Hello,
>
> I would like to open a discussion on the meaning of deprecation warnings in
> 2.7.
> I assume, but I may be wrong, that 2.7 will be the last version in the 2.x
> branch. With this assumption, we should not find many things deprecat
2010/3/3 Florent Xicluna wrote:
>
> I will post a list of the DeprecationWarnings in the python trunk, in a
> followup message, for a review, and to help the discussion.
>
Here is the list of the "Classic" DeprecationWarnings:
http://paste.pocoo.org/show/184931/
And the list of the "Py3k" Depreca
Hey David,
On Mon, Mar 1, 2010 at 7:29 PM, David Malcolm wrote:
> On Mon, 2010-03-01 at 15:35 -0800, Collin Winter wrote:
[snip]
>> - How would you prefer to build the JIT-less package (current options:
>> via a ./configure flag; or by deleting _llvmjit.so from the
>> JIT-enabled package)?
>> - W
Hello,
I would like to open a discussion on the meaning of deprecation warnings in 2.7.
I assume, but I may be wrong, that 2.7 will be the last version in the 2.x
branch. With this assumption, we should not find many things deprecated in 2.7
final.
On the other hand, the list of py3k deprecation
On Tue, Mar 2, 2010 at 11:52 AM, Barry Warsaw wrote:
> On Mar 02, 2010, at 09:34 AM, Guido van Rossum wrote:
>
>>On Tue, Mar 2, 2010 at 5:03 AM, Nick Coghlan wrote:
>>> P.S. I actually started this thread as a +0 to the idea of dropping
>>> bytecode only imports. Over the course of the discussion
On Mar 02, 2010, at 10:54 PM, Martin v. Löwis wrote:
>Correct - I deleted the DNS record, and the site, as it didn't work
>anymore (and because Barry confirmed that it is ok to delete the site)
Yep, sorry. I didn't realize it was still in use.
-Barry
signature.asc
Description: PGP signature
_
> It seems someone has decided that code.python.org doesn't resolve
> anymore.
Correct - I deleted the DNS record, and the site, as it didn't work
anymore (and because Barry confirmed that it is ok to delete the site)
> This is annoying since there were Mercurial mirrors there
> ( at http://code.
Neil Hodgson wrote:
> Martin v. Löwis:
>
>> See http://bugs.python.org/issue6926
>>
>> The SDK currently hides symbolic constants from us that people are
>> asking for.
>
>Setting the version to 0x501 (XP) doesn't actively try to stop
> running on version 0x500 (2K), it just reveals the symbo
On Tue, Mar 2, 2010 at 02:06, Steven D'Aprano wrote:
> On Tue, 2 Mar 2010 11:59:55 am Barry Warsaw wrote:
> > Thanks everybody for providing great input on this aspect of the PEP.
> > I've updated the open issues section to include a list of the
> > possible resolutions for bytecode-only imports
On Mar 02, 2010, at 09:34 AM, Guido van Rossum wrote:
>On Tue, Mar 2, 2010 at 5:03 AM, Nick Coghlan wrote:
>> P.S. I actually started this thread as a +0 to the idea of dropping
>> bytecode only imports. Over the course of the discussion I've shifted to
>> a firm -1 in the absence of some proper
On Tue, Mar 2, 2010 at 5:03 AM, Nick Coghlan wrote:
> P.S. I actually started this thread as a +0 to the idea of dropping
> bytecode only imports. Over the course of the discussion I've shifted to
> a firm -1 in the absence of some proper comparative benchmarks to
> justify the change in semantics
Hello,
It seems someone has decided that code.python.org doesn't resolve
anymore.
This is annoying since there were Mercurial mirrors there
( at http://code.python.org/hg ). Until we make the official switch,
these mirrors are still useful.
Regards
Antoine.
___
Barry Warsaw wrote:
> Thanks everybody for providing great input on this aspect of the PEP. I've
> updated the open issues section to include a list of the possible resolutions
> for bytecode-only imports. Unless anybody has more ideas, it might just be
> time to get a BDFL pronouncement.
I thin
On Sun, Feb 28, 2010 at 1:39 AM, Greg Ewing wrote:
> Meador Inge wrote:
>
>> Even with the user-defined precision capabilities of the 'Decimal' class?
>> In other words, can I create an instance of a 'Decimal' that behaves (in
>> all operations: arithmetic, comparison, etc...) exactly as the exte
On Fri, Feb 26, 2010 at 4:51 AM, Meador Inge wrote:
>
> Recently some discussion began in the issue 3132 thread
> (http://bugs.python.org/issue3132) regarding
> implementation of the new struct string syntax for PEP 3118. Mark Dickinson
> suggested that I bring the discussion on over to Python D
On Tue, 2 Mar 2010 11:59:55 am Barry Warsaw wrote:
> Thanks everybody for providing great input on this aspect of the PEP.
> I've updated the open issues section to include a list of the
> possible resolutions for bytecode-only imports. Unless anybody has
> more ideas, it might just be time to ge
On Tue, 2 Mar 2010 11:41:52 am Barry Warsaw wrote:
> After PEP 3147 is implemented, and the default, you'll have to
> byte-compile the files, then find the pycs in the __pycache__
> directory, move them up a level and rename them. Then of course
> remove the .py files.
>
> It's not insurmountable
Stefan Behnel, 02.03.2010 10:06:
> I just noticed that the xml.etree.ElementTree.tostring() function in Py3.2
> returns a str object by default, unless an encoding is specified. This is a
> backwards incompatible change compared to ET 1.2. For one, it breaks tons
> of tests in lxml's compatibility
Neil Hodgson wrote:
There
is the question of whether to force failure on Windows 2000 or just
remove it from the list of known-working platforms while still
allowing it to run.
I'd be grateful if you could refrain from doing anything to
actively break it. Win 2000 was the last version to be fre
Martin v. Löwis:
> See http://bugs.python.org/issue6926
>
> The SDK currently hides symbolic constants from us that people are
> asking for.
Setting the version to 0x501 (XP) doesn't actively try to stop
running on version 0x500 (2K), it just reveals the symbols and APIs
from 0x501. Including
Hi,
I just noticed that the xml.etree.ElementTree.tostring() function in Py3.2
returns a str object by default, unless an encoding is specified. This is a
backwards incompatible change compared to ET 1.2. For one, it breaks tons
of tests in lxml's compatibility test suite. Previously, the default
30 matches
Mail list logo
