[Python-Dev] ElementTree.tostring() returning str by default in Py3.2

2010-03-02 Thread Stefan Behnel 
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
encoding was 'ASCII', and tostring() was guaranteed to always return a byte
string.

According to svn blame, this was changed by GvR in rev. 56841.

Is there any reasoning behind this?

Stefan

___
Python-Dev mailing list
[email protected]
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 and Windows 2000

2010-03-02 Thread Neil Hodgson 
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 a call to an 0x501-specific API will then fail
at load.

IPPROTO_IPV6 (the cause of issue 6926) isn't a new symbol that
started working in Windows XP - it was present in older SDKs without a
version guard so was visible when compiling for any version of
Windows.

> In addition, we could simplify the code in dl_nt.c around
> GetCurrentActCtx and friends, by linking to these functions directly.

   It would be simpler but its not as if this code needs any changes
at this point.

   I don't really have a strong need for Windows 2000 although I keep
an instance for checking compatibility of my code and I do still get
queries from people using old versions of Windows, including 9x. 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.

   Neil
___
Python-Dev mailing list
[email protected]
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 and Windows 2000

2010-03-02 Thread Greg Ewing 

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 free
of Microsoft DRM crap, and I'd be unhappy if I were forced
to downgrade to a later version just so I could use Py3 on
it.

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ElementTree.tostring() returning str by default in Py3.2

2010-03-02 Thread Stefan Behnel 
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 suite. Previously, the default
> encoding was 'ASCII', and tostring() was guaranteed to always return a byte
> string.
> 
> According to svn blame, this was changed by GvR in rev. 56841.
> 
> Is there any reasoning behind this?

BTW, sorry for not reporting this earlier (the change is from 2007). It
seems that bug 7173 (or some other bug) prevented me from running lxml's
test suite in Py3 for quite a while now. This is the first time in ages
that I get a complete run in Py3.x (x>0).

Stefan

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

Re: [Python-Dev] __file__

2010-03-02 Thread Steven D'Aprano 
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 of course, I think if we support pyc-only
> imports, people are rightly going to want us to write and support the
> tool to create those imports.

Surely that's a job for a tiny Python script, or even a shell script? It 
doesn't sound hard, not from the description given. I imagine there 
will be recipes on ActiveState quite quickly, and if there isn't, that 
would be good evidence that demand for the feature is low.



-- 
Steven D'Aprano
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __file__

2010-03-02 Thread Steven D'Aprano 
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 get a BDFL pronouncement.

Please excuse me if these minor points have already been discussed, but 
I couldn't see them in the PEP.

(1) What happens if the __cache__ directory doesn't exist and the 
enclosing directory is unwriteable, or if it does exist, but is 
unreadable?

I expect that the byte code files will simply not be created, and 
everything will continue without them.

(2) Presumably this only effects imports, not running python source code 
as a script. If I do this:

python myscript.py

from the shell, I would expect that no __cache__ directory will be 
created, just like today. 

BTW, you have some sort of automated warning in the PEP:

System Message: WARNING/2 (pep-3147.txt, line 237)
Title underline too short.

http://www.python.org/dev/peps/pep-3147/#id47



-- 
Steven D'Aprano
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3188: Implementation Questions

2010-03-02 Thread Mark Dickinson 
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 Dev.  Below is a 
> summary
> of the questions\comments from the thread.

Thanks for bringing this up here!

> Unpacking a long-double
> ===
> ...

I don't want to dwell on this too much, since this is just one small
part of the proposed struct module additions, and I'd like to get
answers to some of the other questions you raised.  If interested
parties (Carl?, Travis?) have time to comment on the other questions
Meador raised, I'd *really* appreciate it!

For long-double: I'm essentially -1 on any Decimal involvement here,
on the basis that the semantics are messy and I doubt that the
resulting behaviour would match users' needs or expectations.  I'm
also not too keen on introducing a long-double-with-arithmetic type
(wherever it ends up living);  I think having a single (binary)
floating-point type has served Python very well, and adding other
binary float precisions would risk either adding significant
complexity, or leaving the extended precision type somewhat crippled.
If there were a long double type that supported arithmetic, how should
mixed-mode double + long double operations behave?  What about
conversions of long doubles to and from decimal strings?  Should math
module and cmath module functions accept long double arguments, and if
so, what type result should they produce?  The fact that there are at
least 3 different common formats, before considering padding and byte
order, for long double (IEEE 80-bit extended used on x86, IEEE
binary128, and the so-called double-double format) isn't going to make
things any easier here.

I guess, in my currently not-very-informed state, I'd vote for:

  - packing and unpacking with the long double format expects and
produces a ctypes.long_double in native mode;  the long-double format
would match that of the platform.
  - non-native mode packing and unpacking aren't permitted, and raise
an exception.
  - to do arithmetic with long doubles, users would simply have to
convert to and from Python floats, accepting the loss of precision
that such conversion entails.

But I think I'm failing to understand the intended use-cases for this
(and other) additions.  Would it be possible for Carl or Travis, or
anyone else, to give some examples of situations where this would be
useful?  I don't doubt that such situations exist;  I'm just not sure
what they are.

> Pointers
> ==
> [...]
> 2. How would unpacking a pointer to a Python Object work out?  Given an
>     address how would the appropriate object to be unpacked be determined?

Again, I'd really like to see some examples of how/when packing and
unpacking pointers to Python objects would be used;  I'm currently
feeling too stupid to understand how this might work in practice.

> 4. For the 'X{}' format (pointer to a function), is this supposed to mean a
>     Python function or a C function?

Ditto for this;  assuming that we're talking about a Python function here.

> String Syntax
> ==
>
> The syntax seems to have transcended verbal description.  I think we
> need to put forth a grammar.

Agreed:  a clear specification is needed.

> Use Cases
> 
>
>    1. What are the real world use cases for these struct string extensions?
>   These should be fleshed out and documented.

+many.

Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3188: Implementation Questions

2010-03-02 Thread Mark Dickinson 
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 extended
>> double precision type offered by a given machine?
>
> It's not precision that's the issue, it's that the number
> base is different. That affects which numbers can
> be represented exactly, and how results that can't be
> represented exactly are rounded.
>
> I would be very surprised if there is a way of configuring
> the Decimal type so that it gives identical results to that
> of any IEEE binary floating point type, including rounding
> behaviour, denormalisation, etc.

I'd be astonished. :)

Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Breaking bytecode only imports (was Re: __file__)

2010-03-02 Thread Nick Coghlan 
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 think the benchmarking in the bytecode-only section is still too weak.
"evidence shows that the extra stats can be fairly costly to start up
time" isn't a valid justification for breaking working code. Doing 4
stat calls instead of 5 on a directory miss just doesn't excite me very
much without some genuine benchmarks across different operating systems
and filesystems showing that reducing the number of stat calls by at
best 20% will result in a measurable reduction in import times for real
modules (where we can expect the import time to be dominated by the
execution of the actual module code rather than the time needed to find
that code in the first place).

Using the sample numbers Robert Collins posted:

# Startup time for bzr (cold cache):
$ drop-caches
$ time bzr --no-plugins revno
5061

real0m8.875s
user0m0.210s
sys 0m0.140s

# Hot cache
$ time bzr --no-plugins revno
5061

real0m0.307s
user0m0.250s
sys 0m0.040s

$ strace -c bzr --no-plugins revno
5061
% time seconds  usecs/call callserrors syscall
-- --- --- - - 
 56.340.04  76   527   read
 28.980.020573   9  2273  1905 open
 14.430.010248  14   734   625 stat
  0.150.000107   0   533   fstat


hot cache:
% time seconds  usecs/call callserrors syscall
-- --- --- - - 
 45.100.000368  92 4   getdents
 19.490.000159   0   527   read
 16.910.000138   1   163   munmap
 10.050.82   254   mprotect
  8.460.69   0  2273  1905 open
  0.000.00   0 8   write
  0.000.00   0   367   close
  0.000.00   0   734   625 stat

Assuming all those stat errors are misses from the import system, we're
looking at reducing that 625 figure down to 500: 125 fewer failed calls.
With a hot cache, the impact is too small for strace to even measure.
With a cold cache, it is 1.75 milliseconds: only 1.25% of the system
time consumed in the script's execution, and not even registering
relative to the 9 second wall clock time.

Without significant measurable performance gains, a mere aesthetic
preference isn't enough to justify inflicting subtle breakage on even a
small subset of our users.

Even aside from the issue of a lack of benchmarks to justify the
breakage, bytecode only imports *cannot* legitimately be broken without
at least one release where they generate Deprecation Warnings.

Cheers,
Nick.

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.

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

[Python-Dev] code.python.org dead?

2010-03-02 Thread Antoine Pitrou 

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.


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

Re: [Python-Dev] Breaking bytecode only imports (was Re: __file__)

2010-03-02 Thread Guido van Rossum 
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.

FWIW, I started at -1 and am still -1. I think the PEP is overreaching
in this aspect; it does not serve the stated purpose of the PEP to
make life easier for distros that share code between Python versions.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Breaking bytecode only imports (was Re: __file__)

2010-03-02 Thread Barry Warsaw 
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 comparative benchmarks to
>> justify the change in semantics.
>
>FWIW, I started at -1 and am still -1. I think the PEP is overreaching
>in this aspect; it does not serve the stated purpose of the PEP to
>make life easier for distros that share code between Python versions.

I think that's fair, and just the guidance I'm looking for.  By now you
understand the pros and cons, so if this is a pronouncement, I will cement it
into the PEP.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __file__

2010-03-02 Thread Brett Cannon 
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.  Unless anybody has
> > more ideas, it might just be time to get a BDFL pronouncement.
>
> Please excuse me if these minor points have already been discussed, but
> I couldn't see them in the PEP.
>
> (1) What happens if the __cache__ directory doesn't exist and the
> enclosing directory is unwriteable, or if it does exist, but is
> unreadable?
>
> I expect that the byte code files will simply not be created, and
> everything will continue without them.
>
> (2) Presumably this only effects imports, not running python source code
> as a script. If I do this:
>
> python myscript.py
>
> from the shell, I would expect that no __cache__ directory will be
> created, just like today.
>
> BTW, you have some sort of automated warning in the PEP:
>
> System Message: WARNING/2 (pep-3147.txt, line 237)
> Title underline too short.
>
> http://www.python.org/dev/peps/pep-3147/#id47


It's now fixed. Barry forgot to run the Makefile for the PEPs before
checking in.  Shame! =)

-Brett




>
>
>
>
> --
> Steven D'Aprano
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
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 and Windows 2000

2010-03-02 Thread Martin v. Löwis 
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 symbols and APIs
> from 0x501. Including a call to an 0x501-specific API will then fail
> at load.
> 
> IPPROTO_IPV6 (the cause of issue 6926) isn't a new symbol that
> started working in Windows XP - it was present in older SDKs without a
> version guard so was visible when compiling for any version of
> Windows.

I'm not proposing to actively break Windows 2000 support. I propose to
stop supporting it, which means that we will not strive for Python
running on Windows 2000, and that bug reports that report issues
specific with Windows 2000 will be closed as "won't fix".

I would not want to bump the SDK version while still aiming at Windows
2000 support - as that gets rarely tested, this API version is actually
a mechanism to simplify ongoing support for Windows 2000.

>I don't really have a strong need for Windows 2000 although I keep
> an instance for checking compatibility of my code and I do still get
> queries from people using old versions of Windows, including 9x. 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 would propose the latter; see above. However, patches that do actively
break it would then be acceptable.

In any case, we would need a warning in the installer that Windows 2000
supports is going away.

Regards,
Martin

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

Re: [Python-Dev] code.python.org dead?

2010-03-02 Thread Martin v. Löwis 
> 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.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 could restore it,
but I would need help to make it actually work (such as giving it a
working DocumentRoot).

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] code.python.org dead?

2010-03-02 Thread Barry Warsaw 
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
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Breaking bytecode only imports (was Re: __file__)

2010-03-02 Thread Guido van Rossum 
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 I've shifted to
>>> a firm -1 in the absence of some proper comparative benchmarks to
>>> justify the change in semantics.
>>
>>FWIW, I started at -1 and am still -1. I think the PEP is overreaching
>>in this aspect; it does not serve the stated purpose of the PEP to
>>make life easier for distros that share code between Python versions.
>
> I think that's fair, and just the guidance I'm looking for.  By now you
> understand the pros and cons, so if this is a pronouncement, I will cement it
> into the PEP.

Yes, and thanks!

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Deprecation warnings in Python 2.7

2010-03-02 Thread Florent Xicluna 
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 warnings is increasing a lot.
And more users will probably start to move from 2.7 to the 3.1 release.

While working on ticket #7092 and #7849, we started to discuss some proposals
to simplify the deprecation warnings for 2.7.

We discussed these 2 proposals:

 1) in 2.6 there's no distinction between py3k and normal deprecations: they
share the same category, DeprecationWarning.  The "-3" switch enables the
py3k DeprecationWarning and SyntaxWarning.
Do we need to introduce a subclass Py3kDeprecationWarning in 2.7?  It will
make it easier to separate both kinds of deprecations (2.x and 3.x), and
to filter them.

 2) a different idea is to deprecate the "-3" switch and consider all py3k
deprecations as normal deprecations.  They will be hidden by default
thanks to #7309.  Since there's no future for the 2.x branch, it seems
normal to consider the migration from 2.7 to 3.1 and show these warnings
when the developer uses "-Wd" switch.

What do you expect as DeprecationWarning in 2.7?

I will post a list of the DeprecationWarnings in the python trunk, in a
followup message, for a review, and to help the discussion.

Best regards,

-- 
Florent Xicluna


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

Re: [Python-Dev] Packaging JIT-less versions of Python

2010-03-02 Thread Collin Winter 
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)?
>> - Would the two packages be able to exist side-by-side, or would they
>> be mutually exclusive?
>
> I have a particular interest in ABI compatibility: if turning JIT on and
> off is going to change the ABI of extension modules, that would be a
> major pain, as I hope that we will have dozens of C extension modules
> available via RPM for our Python 3 stack by the time of the "great
> unladen merger".

Do you have a good way of testing ABI compatibility, or is it just
"build modules, see if they work"? Some general way of testing ABI
compatibility would be really useful for PEP 384, too.

> So I'm keen for the ability to toggle the JIT code in the face of bugs
> and have it not affect ABI.  "-Xjit" will do this at runtime (once
> that's renamed), but I think it would be useful to be able to toggle the
> JIT on/off default during the build, so that I can fix a broken
> architecture for non-technical users, but have individual testers opt
> back in with -Xjit whilst tracking down a major bug.

That's something we can definitely do: you'd just change the default
value for the -Xjit flag from "whenhot" to "never". Those individual
testers would pass -Xjit=whenhot to opt back in. We could make that a
./configure flag if it would be useful to you and the other distros.

> In either case, I don't want to have to recompile 30 extension modules
> to try with/without JIT; that would introduce too much change during
> bug-hunts, and be no fun at all.

That would suck indeed; I want to avoid that. I think that kind of
thing falls under PEP 384, which we will have to obey once it is
accepted.

> (In the blue-sky nirvana future, I'd love to be able to ship
> ahead-of-time compiled versions of the stdlib, pre-optimized based on
> realworld workloads.  Back in my reality, though, I have bugs to fix
> before I can work on _that_ patch :( )

Reid Kleckner may be looking at that for his Master's project. It's
definitely doable.

>> My strong preference would be to have the JIT included by default so
>> that it receives as much testing as possible.
>
> Sounds reasonable.  Hope the above made sense and is useful.

Thanks for your perspective,
Collin Winter
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecation warnings in Python 2.7

2010-03-02 Thread Florent XICLUNA 
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" DeprecationWarnings and SyntaxWarnings:
http://paste.pocoo.org/show/184932/

I expect most of the things in the first list to be removed in 2.7
instead of being only deprecated.

Then what is the best approach:
 1) to separate better the Py3k warnings giving them a specific
subclass Py3kDeprecationWarnings
 2) to merge both lists because we consider deprecation related to 3.1
(and newer) ?
 3) to keep things unchanged?


-- 
Florent
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecation warnings in Python 2.7

2010-03-02 Thread Brett Cannon 
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 deprecated in
> 2.7
> final.
>
> On the other hand, the list of py3k deprecation warnings is increasing a
> lot.
> And more users will probably start to move from 2.7 to the 3.1 release.
>
> While working on ticket #7092 and #7849, we started to discuss some
> proposals
> to simplify the deprecation warnings for 2.7.
>
> We discussed these 2 proposals:
>
>  1) in 2.6 there's no distinction between py3k and normal deprecations:
> they
>share the same category, DeprecationWarning.  The "-3" switch enables
> the
>py3k DeprecationWarning and SyntaxWarning.
>Do we need to introduce a subclass Py3kDeprecationWarning in 2.7?  It
> will
>make it easier to separate both kinds of deprecations (2.x and 3.x), and
>to filter them.
>
>  2) a different idea is to deprecate the "-3" switch and consider all py3k
>deprecations as normal deprecations.  They will be hidden by default
>thanks to #7309.  Since there's no future for the 2.x branch, it seems
>normal to consider the migration from 2.7 to 3.1 and show these warnings
>when the developer uses "-Wd" switch.
>
> What do you expect as DeprecationWarning in 2.7?
>

I like option 2; we are serious about trying to make 2.7 the last in the 2.x
series, which means if you care about deprecations then you are caring about
Python 3. So I say make -3 the equivalent of -Wd in Python 2.7

-Brett



>
> I will post a list of the DeprecationWarnings in the python trunk, in a
> followup message, for a review, and to help the discussion.
>
> Best regards,
>
> --
> Florent Xicluna
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecation warnings in Python 2.7

2010-03-02 Thread Raymond Hettinger 

> 
> 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 deprecated in 
> 2.7
> final.
> 
> On the other hand, the list of py3k deprecation warnings is increasing a lot.
> And more users will probably start to move from 2.7 to the 3.1 release.
> 
> While working on ticket #7092 and #7849, we started to discuss some proposals
> to simplify the deprecation warnings for 2.7.
> 
> We discussed these 2 proposals:
> 
>  1) in 2.6 there's no distinction between py3k and normal deprecations: they
>share the same category, DeprecationWarning.  The "-3" switch enables the
>py3k DeprecationWarning and SyntaxWarning.
>Do we need to introduce a subclass Py3kDeprecationWarning in 2.7?  It will
>make it easier to separate both kinds of deprecations (2.x and 3.x), and
>to filter them.
> 
>  2) a different idea is to deprecate the "-3" switch and consider all py3k
>deprecations as normal deprecations. 

-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 shooting ourselves in the foot.

2) There is some chance that there will be a 2.8, so it isn't helpful to burn 
down our bridges.

ISTM, nothing is currently broken and in need of "fixing" in 2.7.
I don't see any advantage to conflating py3k warnings with other deprecations.


Raymond___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Caching function pointers in type objects

2010-03-02 Thread 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?
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Caching function pointers in type objects

2010-03-02 Thread Benjamin Peterson 
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?

Not unless it's builtin. Somebody could have deleted the rich
comparison methods.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Caching function pointers in type objects

2010-03-02 Thread Reid Kleckner 
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 should depend on.

Reid

On Tue, Mar 2, 2010 at 9:57 PM, Benjamin Peterson  wrote:
> 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?
>
> Not unless it's builtin. Somebody could have deleted the rich
> comparison methods.
>
>
>
> --
> Regards,
> Benjamin
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/reid.kleckner%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python 2.6.5 release candidate 1 now available

2010-03-02 Thread Barry Warsaw 
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 will do the final
release on Monday March 15, 2010.  Please test the release candidate as
much as possible in the meantime, and help make 2.6.5 a rock solid release!

Thanks,
-Barry

P.S. The Mac installer will hopefully be available soon.


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] code.python.org dead?

2010-03-02 Thread Antoine Pitrou 
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 could restore it,
> but I would need help to make it actually work (such as giving it a
> working DocumentRoot).

I actually sent a template of the actual Apache configuration long ago,
to Neil Schemenauer I think (my memory may be failing on that).

I normally have ssh access to the machine using the "svn2hg" account,
but I don't think I can actually use that account until I return from
vacation - that is, until mid-March. The setup was a quite standard
hgwebdir wsgi script hooked into mod_wsgi.

Also, if the mirrors themselves have been wiped as well, they will have
to be regenerated (hopefully yielding the same changeset ids :-)).

Regards

Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecation warnings in Python 2.7

2010-03-02 Thread 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 the -3 switch seems like
> shooting ourselves in the foot.
> 
> 2) There is some chance that there will be a 2.8, so it isn't helpful
> to burn down our bridges.

That's my feeling too. I think introducing a Py3kDeprecationWarning
subclass is the right thing to do.

Regards

Antoine.


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

Re: [Python-Dev] Deprecation warnings in Python 2.7

2010-03-02 Thread Benjamin Peterson 
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 the -3 switch seems like
>> shooting ourselves in the foot.
>>
>> 2) There is some chance that there will be a 2.8, so it isn't helpful
>> to burn down our bridges.
>
> That's my feeling too. I think introducing a Py3kDeprecationWarning
> subclass is the right thing to do.

Not to bikeshed, but I think it should be called Py3DeprecationWarning
in light of the fact that Python 3 is no longer a mythical beast. :)



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ElementTree.tostring() returning str by default in Py3.2

2010-03-02 Thread Stefan Behnel 

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 suite. Previously, the default
encoding was 'ASCII', and tostring() was guaranteed to always return a byte
string.

According to svn blame, this was changed by GvR in rev. 56841.

Is there any reasoning behind this?


I filed a bug report for now.

http://bugs.python.org/issue8047

Stefan

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