Re: [Python-Dev] Reworking the GIL
2009/11/7 Antoine Pitrou > > Hello again, > > > It shows that, on my platform for this specific benchmark: > > * newgil manage to leverage a significant amount of parallelism > > (1.7) where python 3.1 does not (3.1 is 80% slower) > > I think you are mistaken: > > -j0 (main thread only) > newgil: 47.483s, 47.605s, 47.512s > -j4 (4 consumer threads, main thread producing/waiting) > newgil: 48.428s, 49.217s > > The runtimes are actually the same, so newgil doesn't leverage anything. > However, it doesn't degrade performance like 2.x/3.1 does :-) > Ooops, I was comparing to 3.1 -j4 times which make no sense. One would think I wanted to see that result since I though the GIL was released :/. This greatly reduce the interest of this benchmark... > > * 3.1 is more than 2 times slower than python 2.6 on this > > benchmark > > That's the most worrying outcome I'd say. Are you sure the benchmark > really does the same thing? Under 2.6, you should add re.UNICODE to the > regular expression flags so as to match the 3.x semantics. > I've tried, but there is no change in result (the regexp does not use \w & co but specify a lot unicode ranges). All strings are already of unicode type in 2.6. > > [if I understood correctly in 3.x regex release the GIL]. > > Unless I've missed something it doesn't, no. > Hmmm, I was confusing with other modules (bzip2 & hashlib?). Looking back at the result of your benchmark it's obvious. Is there a place where the list of functions releasing the GIL is available? I did not see anything in bz2.compress documentation. ___ 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] Reworking the GIL
Baptiste Lepilleur gmail.com> writes: > > I've tried, but there is no change in result (the regexp does not use \w & > co but specify a lot unicode ranges). All strings are already of unicode > type in 2.6. No they aren't. You should add "from __future__ import unicode_literals" at the start of your script and run it again. > Hmmm, I was confusing with other modules (bzip2 & hashlib?). Looking back at > the result of your benchmark it's obvious. Is there a place where the list of > functions releasing the GIL is available? I did not see anything in > bz2.compress documentation. No, there isn't. You'd have to test, or read the source code. But bz2 and zlib, for example, do release the GIL. 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
[Python-Dev] decimal.py: == and != comparisons involving NaNs
Hi,
in a (misguided) bugreport (http://bugs.python.org/issue7279) I was
questioning the reasons for allowing NaN comparisons with == and !=
rather than raising InvalidOperation.
I think two main issues emerge from the brief discussion:
1. Should the comparison operators follow the 'compare' function
from the standard?
The standard says:
"An implementation may use this operation [compare] under the covers to
implement a closed set of comparison operations (greater than, equal, etc.)
if desired. It need not, in this case, expose the compare operation
itself."
So, I'd say that this supports following 'compare' as closely as possible.
In fact the operators <, <=, >, >= already follow 'compare-signal' in
their behavior (they raise for any NaN operand).
2. What is the use of == and != outside the decimal scope?
Mark mentions that Python uses == to test for set and dict memberships,
but that you cannot put decimal NaNs into sets:
'TypeError: Cannot hash a NaN value'
I want to add that Decimal('NaN') == Decimal('NaN') gives False, which
should somewhat limit the uses of == for NaNs outside the decimal realm
anyway.
Are there cases where == and != are actually needed to give a result
for NaNs?
Stefan Krah
___
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] Status of the Buildbot fleet and related bugs
> JFTR, I didn't set up the IRC bot (I assume that credit goes to Martin, > even if it's only one line in the buildbot config :). I just tried to > get it to say something :) Yes, it was always "on". I don't use IRC regularly, so I don't know whether it's useful. 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] decimal.py: == and != comparisons involving NaNs
[Stefan Krah] in a (misguided) bugreport (http://bugs.python.org/issue7279) I was questioning the reasons for allowing NaN comparisons with == and != rather than raising InvalidOperation. Do you have any actual use case issues or are these theoretical musings? I ask only because a good use case might suggest the best way to adapt the standard to the regular python api for equality/inequality operators. NaNs are odd ducks. They are unique in violating our basic notions of equality (any relation that is reflexsive, symmetric, and transitive). Once you use them in a context that goes beyond the decimal spec, it is no surprise that you run into difficulties where NaNs don't fit very well (because they violate basic assumptions and invariants in other code). Are there cases where == and != are actually needed to give a result for NaNs? I would say that anywhere someone needs the full behaviors specified by the standard, they need to use the actual compare() method which allows for a decimal context to be specified and allows for more than just a true/false return value (i.e. a NaN is a possible result). 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
Re: [Python-Dev] OpenSSL vulnerability
>> Also, for Python 2.5 and earlier, any SSL-based code is vulnerable to a MitM >> anyway, so this can only be an issue for code using the new APIs in Python >> 2.6. > > That's not going to stop the > wannabe-self-proclaimed-so-called-vulnerability-"experts" from whining > about Python not releasing updated binary distributions though. :-( The Windows binaries currently build with 0.9.8g. Since changing that would be a source code change (even though just a single line), I think a full source release would be necessary (most likely then for both 2.6 and 3.1). 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] decimal.py: == and != comparisons involving NaNs
Stefan Krah bytereef.org> writes:
>
> Are there cases where == and != are actually needed to give a result
> for NaNs?
It is a common expectation that == and != always succeed. They return True or
False, but don't raise an exception even on unrelated operands:
>>> b"a" == "a"
False
>>> "5" == 5
False
>>> {} == 0.0
False
>>> None == (lambda x: 1)
False
>>> int == max
False
The only place I know of where this expectation isn't met is when comparing
"naive" and "timezone-aware" datetime objects, which raises a TypeError (IIRC).
___
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 3003 - Python Language Moratorium
John Arbash Meinel wrote: He wanted to introduce a moratorium at least partially because he was tired of endless threads about anonymous code blocks, etc. Which aren't going to be included in the language anyway, so he may as well make a point to say "and neither will anything else for a while". I have not said anything on this topic either way. But I think a general moratorium is a false solution to that particular problem. Guido should just make a clear pronouncement (again) and let people quote that in response to initial posts, before they *appear* to gain steam. Each time Python doubles in popularity, the number of people wanting such things will approximately double. That is the price of success. Terry Jan Reedy ___ 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] Status of the Buildbot fleet and related bugs
On Sun, 8 Nov 2009 at 19:44, "Martin v. L?wis" wrote: JFTR, I didn't set up the IRC bot (I assume that credit goes to Martin, even if it's only one line in the buildbot config :). I just tried to get it to say something :) Yes, it was always "on". I don't use IRC regularly, so I don't know whether it's useful. I think it is. --David (RDM)___ 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 3003 - Python Language Moratorium
On Thu, Nov 5, 2009 at 4:13 PM, Yuvgoog Greenle wrote: > On Fri, Nov 6, 2009 at 1:55 AM, Bobby R. Ward wrote: >> >> A switch to ENABLE those warnings? >> > > I think a few people I know would still be raising strings like exceptions > if not for the deprecation warnings. Most people won't turn on the switch > with the extra warnings. > --yuv Yep and their code will break in the future as a result. Thats their problem (or whoever employed them and neglected to do code reviews and beat them with a stick for using a Python 1.x "feature" in 2009). SUGGESTION: Our Whats New document currently has a single "new, improved and deprecated" section in it. We should make Deprecations its own section so that they're easy to find all in one concise place when upgrading code between releases. Having seen the fallout from adding deprecating warnings to code: many annoyed developers whos workflow you've interrupted who will all eventually turn the warning off by default at all times. I have to agree. The DeprecationWarning being on by default is a failed experiement. We should treat it and the rarely noticed PendingDeprecationWarning as the same thing by default. -gps ___ 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] OpenSSL vulnerability
Guido van Rossum schrieb: > On Fri, Nov 6, 2009 at 2:36 PM, wrote: >> Also, for Python 2.5 and earlier, any SSL-based code is vulnerable to a MitM >> anyway, so this can only be an issue for code using the new APIs in Python >> 2.6. > > That's not going to stop the > wannabe-self-proclaimed-so-called-vulnerability-"experts" from whining > about Python not releasing updated binary distributions though. :-( Yet it has been quiet on the Finnish front so far :) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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 3003 - Python Language Moratorium
John Arbash Meinel wrote: He wanted to introduce a moratorium at least partially because he was tired of endless threads about anonymous code blocks, etc. Which aren't going to be included in the language anyway, so he may as well make a point to say "and neither will anything else for a while". If anonymous code blocks still get discussed even when they have no chance of being accepted, this suggests that a moratorium is *not* going to stop discussion of new features. I'm a bit confused about Guido's reasons for wanting a moratorium. He started out by saying that the intention wasn't to stop people discussing ideas, then later he seemed to say that he was finding all these discussions were distracting, then he explicitly said he wanted to "crush" people's hopes of getting new features into the language. That all sounds like he actually *does* want to discourage such discussions. -- 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] PEP 3003 - Python Language Moratorium
Gregory P. Smith schrieb: > On Thu, Nov 5, 2009 at 4:13 PM, Yuvgoog Greenle wrote: >> On Fri, Nov 6, 2009 at 1:55 AM, Bobby R. Ward wrote: >>> >>> A switch to ENABLE those warnings? >>> >> >> I think a few people I know would still be raising strings like exceptions >> if not for the deprecation warnings. Most people won't turn on the switch >> with the extra warnings. >> --yuv > > Yep and their code will break in the future as a result. Thats their > problem (or whoever employed them and neglected to do code reviews and > beat them with a stick for using a Python 1.x "feature" in 2009). > > SUGGESTION: Our Whats New document currently has a single "new, > improved and deprecated" section in it. We should make Deprecations > its own section so that they're easy to find all in one concise place > when upgrading code between releases. Good point, I'll make that change if AMK agrees. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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 3003 - Python Language Moratorium
Greg Ewing canterbury.ac.nz> writes: > > If anonymous code blocks still get discussed even when > they have no chance of being accepted, this suggests that > a moratorium is *not* going to stop discussion of new > features. Well, if they get discussed, it's probably that some people can't help participating in the discussions, even though they know the idea is doomed to failure ;) ___ 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 3003 - Python Language Moratorium
On Sun, 8 Nov 2009 11:14:59 am Steven D'Aprano wrote: > At the very least, I believe, any moratorium should have a clear end > date. A clear end date will be a powerful counter to the impression > that Python the language is moribund. It says, this is an exceptional > pause, not a permanent halt. Proposal: No new language features in odd-numbered point releases (3.3, 3.5, ...). Even-numbered point releases (3.4, 3.6, ...) may include new language features provided they meet the usual standards for new features. 3.2 is a special case: as an even-numbered release, it would normally allow new features, but in recognition of the special nature of the 2.x to 3.1/3.2 migration, no new language features will be allowed. Advantages: * It slows down changes to the language while still allowing sufficiently high-standard new features. * Alternate implementations have a stable language version to aim for. Assuming point releases come ever 12-18 months, that stable language version will last 2-3 years. * It doesn't have the psychological baggage of an unconditional ban on new features for the indefinite future. It gives a fixed, known schedule for when new features will be permitted, without the uncertainty of "at the BDFL's pleasure". -- 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 3003 - Python Language Moratorium
On Sun, Nov 8, 2009 at 6:06 PM, Steven D'Aprano wrote: > On Sun, 8 Nov 2009 11:14:59 am Steven D'Aprano wrote: >> At the very least, I believe, any moratorium should have a clear end >> date. A clear end date will be a powerful counter to the impression >> that Python the language is moribund. It says, this is an exceptional >> pause, not a permanent halt. > > Proposal: > > No new language features in odd-numbered point releases (3.3, 3.5, ...). > Even-numbered point releases (3.4, 3.6, ...) may include new language > features provided they meet the usual standards for new features. > > 3.2 is a special case: as an even-numbered release, it would normally > allow new features, but in recognition of the special nature of the 2.x > to 3.1/3.2 migration, no new language features will be allowed. > > Advantages: > > * It slows down changes to the language while still allowing > sufficiently high-standard new features. > > * Alternate implementations have a stable language version to aim for. > Assuming point releases come ever 12-18 months, that stable language > version will last 2-3 years. > > * It doesn't have the psychological baggage of an unconditional ban on > new features for the indefinite future. It gives a fixed, known > schedule for when new features will be permitted, without the > uncertainty of "at the BDFL's pleasure". > > > -- > Steven D'Aprano FWIW, I view a definite end point as a definite plus. Geremy Condra ___ 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 3003 - Python Language Moratorium
On Nov 8, 2009, at 7:01 PM, geremy condra wrote: On Sun, Nov 8, 2009 at 6:06 PM, Steven D'Aprano wrote: On Sun, 8 Nov 2009 11:14:59 am Steven D'Aprano wrote: At the very least, I believe, any moratorium should have a clear end date. A clear end date will be a powerful counter to the impression that Python the language is moribund. It says, this is an exceptional pause, not a permanent halt. Proposal: No new language features in odd-numbered point releases (3.3, 3.5, ...). Even-numbered point releases (3.4, 3.6, ...) may include new language features provided they meet the usual standards for new features. 3.2 is a special case: as an even-numbered release, it would normally allow new features, but in recognition of the special nature of the 2.x to 3.1/3.2 migration, no new language features will be allowed. Advantages: * It slows down changes to the language while still allowing sufficiently high-standard new features. * Alternate implementations have a stable language version to aim for. Assuming point releases come ever 12-18 months, that stable language version will last 2-3 years. * It doesn't have the psychological baggage of an unconditional ban on new features for the indefinite future. It gives a fixed, known schedule for when new features will be permitted, without the uncertainty of "at the BDFL's pleasure". -- Steven D'Aprano FWIW, I view a definite end point as a definite plus. Geremy Condra There is a time outlined in the pep. ___ 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] raw binary data and 2to3
SpamBayes has several files which contain raw 8-bit data embedded in string literals. Before I do manual work to make them parseable by 2to3 I thought I would ask if there was either a fixer available which I'm not getting by default or if there is an opportunity to add a new fixer to 2to3. The usage is pretty straightforward. For example, a string literal might contain the bytes for a GIF image: data = "GIF89a(..." Is there a potentially automated path from where the code is today to something Python 3 (and 2to3) will like? Skip ___ 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 3003 - Python Language Moratorium
On Sun, Nov 8, 2009 at 8:22 PM, Jesse Noller wrote: > > > On Nov 8, 2009, at 7:01 PM, geremy condra wrote: > >> On Sun, Nov 8, 2009 at 6:06 PM, Steven D'Aprano >> wrote: >>> >>> On Sun, 8 Nov 2009 11:14:59 am Steven D'Aprano wrote: At the very least, I believe, any moratorium should have a clear end date. A clear end date will be a powerful counter to the impression that Python the language is moribund. It says, this is an exceptional pause, not a permanent halt. >>> >>> Proposal: >>> >>> No new language features in odd-numbered point releases (3.3, 3.5, ...). >>> Even-numbered point releases (3.4, 3.6, ...) may include new language >>> features provided they meet the usual standards for new features. >>> >>> 3.2 is a special case: as an even-numbered release, it would normally >>> allow new features, but in recognition of the special nature of the 2.x >>> to 3.1/3.2 migration, no new language features will be allowed. >>> >>> Advantages: >>> >>> * It slows down changes to the language while still allowing >>> sufficiently high-standard new features. >>> >>> * Alternate implementations have a stable language version to aim for. >>> Assuming point releases come ever 12-18 months, that stable language >>> version will last 2-3 years. >>> >>> * It doesn't have the psychological baggage of an unconditional ban on >>> new features for the indefinite future. It gives a fixed, known >>> schedule for when new features will be permitted, without the >>> uncertainty of "at the BDFL's pleasure". >>> >>> >>> -- >>> Steven D'Aprano >> >> >> FWIW, I view a definite end point as a definite plus. >> >> Geremy Condra >> > > There is a time outlined in the pep. > I quote: "This PEP proposes a temporary moratorium (suspension) of all changes to the Python language syntax, semantics, and built-ins for a period of *at least two years* from the release of Python 3.1." Emphasis mine. Like I say, a definite end point would be much preferred to n > 2. If possible, I'd also like to hear some of Steven's other points addressed. Geremy Condra ___ 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] raw binary data and 2to3
2009/11/8 : > > SpamBayes has several files which contain raw 8-bit data embedded in > string literals. Before I do manual work to make them parseable by 2to3 > I thought I would ask if there was either a fixer available which I'm > not getting by default or if there is an opportunity to add a new fixer > to 2to3. > > The usage is pretty straightforward. For example, a string literal > might contain the bytes for a GIF image: > > data = "GIF89a(..." > > Is there a potentially automated path from where the code is today to > something Python 3 (and 2to3) will like? Not to my knowledge. I would prefer to not add a fixer for this directly to 2to3 because it is not correct for most programs. However, I think 2to3 should grow some sort of plugin system, so custom fixers can easily be written and used. -- 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] PEP 3003 - Python Language Moratorium
On Sun, Nov 8, 2009 at 3:06 PM, Steven D'Aprano wrote: > No new language features in odd-numbered point releases (3.3, 3.5, ...). > Even-numbered point releases (3.4, 3.6, ...) may include new language > features provided they meet the usual standards for new features. Oh no, not the eve/odd numbering scheme. Nobody will be able to remember which is which. -- --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] PEP 3003 - Python Language Moratorium
On Sun, Nov 8, 2009 at 5:45 PM, geremy condra wrote: > I quote: > > "This PEP proposes a temporary moratorium (suspension) of all changes > to the Python language syntax, semantics, and built-ins for a period > of *at least two years* from the release of Python 3.1." > > Emphasis mine. I since added this: """In particular, the moratorium would include Python 3.2 (to be released 18-24 months after 3.1) but (unless explicitly extended) allow Python 3.3 to once again include language changes.""" > Like I say, a definite end point would be much preferred to n > 2. My time machine doesn't work very well in the future. So I can't tell what we'll find necessary 2 years from now. But I would be fine with defining the time limit to be max(time(3.1) + 2 years, time(3.2)). I.e. the moratorium (unless explicitly extended) ends as soon as 3.2 has been released *and* at least 2 years have passed since 3.1. > If possible, I'd also like to hear some of Steven's other points addressed. They haven't changed my mind. -- --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] raw binary data and 2to3
On Sun, Nov 8, 2009 at 5:48 PM, Benjamin Peterson wrote: > 2009/11/8 : >> >> SpamBayes has several files which contain raw 8-bit data embedded in >> string literals. Before I do manual work to make them parseable by 2to3 >> I thought I would ask if there was either a fixer available which I'm >> not getting by default or if there is an opportunity to add a new fixer >> to 2to3. >> >> The usage is pretty straightforward. For example, a string literal >> might contain the bytes for a GIF image: >> >> data = "GIF89a(..." >> >> Is there a potentially automated path from where the code is today to >> something Python 3 (and 2to3) will like? > > Not to my knowledge. I would prefer to not add a fixer for this > directly to 2to3 because it is not correct for most programs. However, > I think 2to3 should grow some sort of plugin system, so custom fixers > can easily be written and used. But if you're happy with only supporting 2.6, you can use b"..." and the right thing will happen. -- --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] raw binary data and 2to3
Guido> But if you're happy with only supporting 2.6, you can use b"..." and Guido> the right thing will happen. SpamBayes still supports 2.4... Thanks for the feedback. I'll update the source manually, then run 2to3. S ___ 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 3003 - Python Language Moratorium
Guido van Rossum wrote: > On Sun, Nov 8, 2009 at 3:06 PM, Steven D'Aprano wrote: >> No new language features in odd-numbered point releases (3.3, 3.5, ...). >> Even-numbered point releases (3.4, 3.6, ...) may include new language >> features provided they meet the usual standards for new features. > > Oh no, not the eve/odd numbering scheme. Nobody will be able to > remember which is which. > In this case, does it really matter? Usually the confusion is with stable/unstable being even/odd or odd/even, but in this case the options are stable/stable (it just happens that certain pairwise versions are related). -- Scott Dial [email protected] [email protected] ___ 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 3003 - Python Language Moratorium
On Sun, Nov 8, 2009 at 9:41 PM, Guido van Rossum wrote: > On Sun, Nov 8, 2009 at 5:45 PM, geremy condra wrote: >> I quote: >> >> "This PEP proposes a temporary moratorium (suspension) of all changes >> to the Python language syntax, semantics, and built-ins for a period >> of *at least two years* from the release of Python 3.1." >> >> Emphasis mine. > > I since added this: > > """In particular, > the moratorium would include Python 3.2 (to be released 18-24 months > after 3.1) but (unless explicitly extended) allow Python 3.3 to once > again include language changes.""" > >> Like I say, a definite end point would be much preferred to n > 2. > > My time machine doesn't work very well in the future. So I can't tell > what we'll find necessary 2 years from now. But I would be fine with > defining the time limit to be max(time(3.1) + 2 years, time(3.2)). > I.e. the moratorium (unless explicitly extended) ends as soon as 3.2 > has been released *and* at least 2 years have passed since 3.1. Ok, thanks for the clarification. Could you spell out what you would consider grounds for a future extension? >> If possible, I'd also like to hear some of Steven's other points addressed. > > They haven't changed my mind. Ok, but the fact that you (or Steven) hold a particular set of beliefs is a singularly unconvincing argument. Could you explain why you don't agree, if only for the record? Geremy Condra ___ 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] decimal.py: == and != comparisons involving NaNs
Antoine Pitrou wrote: Stefan Krah bytereef.org> writes: Are there cases where == and != are actually needed to give a result for NaNs? It is a common expectation that == and != always succeed. They return True or False, but don't raise an exception even on unrelated operands: It is a common expectation, but a false one. __eq__ and __ne__ are explicitly allowed to return anything, not just bools. http://www.python.org/dev/peps/pep-0207/ -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ 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] Status of the Buildbot fleet and related bugs
On Fri, Nov 6, 2009 at 12:27 AM, Mark Dickinson wrote: > On Fri, Nov 6, 2009 at 3:53 AM, R. David Murray wrote: > >> (2) issue 4970: consistent signal 32 error on the norwitz-x86 Gentoo >> buildslave in 3.1 and 3.x. This may be due to the box >> running an old threading library, but it does make one wonder what >> changed in 3.x that exposed it. > > This error has been happening since well before 3.0 was released. Asking > for access to Neal's machine is probably the only sensible way to diagnose > it. (A less invasive but slower way to debug would be to create a branch > especially for this bug and do repeated runs to figure out which part of > test_os > is causing the failure.) IIRC, I spent quite a bit of time trying to nail this down. I don't remember finding any useful information on the cause (beyond narrowing it to some tests). As Mark said, this has been happening for a long time. I'm reticent to provide access to the machine, as it's not really mine. I'm not even sure I have access, I haven't logged in for a long time. I'd just like to say thanks again to everyone for making the buildbots more green and also improving the general testing infrastructure for Python. n ___ 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] IDLE as default Python editor (Was: [pygame] Python IDE for windoz)
Hello, Quite an interesting question recently popped up in pygame community that I'd like to ask to Python developers. How many of you use IDLE? What's wrong with it? >From my side I like the idea of having default Python editor that is small, fast, convenient and extensible/embeddable. IDLE is small and fast, but I feel really uncomfortable with its. The worst thing - I can't change it. Does anybody else feel the same to think if we could replace IDLE with something more maintainable by providing Scintilla bindings, for example? Regards, -- anatoly t. On Sat, Oct 10, 2009 at 8:15 PM, RB[0] wrote: > Most? people just don't like it - personally it's all I use, Windows or > otherwise... > > On Sat, Oct 10, 2009 at 12:23 PM, Kris Schnee wrote: >> >> What's wrong with the built-in editor, IDLE? > > ___ 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] IDLE as default Python editor
anatoly techtonik writes: > Quite an interesting question recently popped up in pygame community > that I'd like to ask to Python developers. This forum is specifically about development *of* Python. You would do better to ask on the discussion forum for Python users http://www.python.org/community/lists/#comp-lang-python>. Or, if you're interested in gauging interest in a new idea for changing Python, you could raise it on the ‘python-ideas’ forum http://news.gmane.org/gmane.comp.python.ideas>. -- \ “The generation of random numbers is too important to be left | `\to chance.” —Robert R. Coveyou | _o__) | Ben Finney ___ 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] Updates to XP-4 and FreeBSD build slaves
I think in a prior discussion, it was suggested that build slave updates were ok for this list - I apologize to those who may not be interested. I've just completed some updates to my two build slaves. XP-4 is now running XP Pro SP3 (was SP2) and is using the full version of VS 2008 (was previously using Express). FreeBSD is now running FreeBSD 6.4-RELEASE (was 6.2-RELEASE). Both are new VMs, and also now use the latest buildbot (0.7.11p3) release. For at least the next few days they are being run on a different host while I do some long-awaited maintenance to the old host. I've done manual builds on both, as well as reissuing a few builds through the master, but if anyone notices anything strange please feel free to drop me a note. -- David PS: I did discover one interesting bug by starting fresh on Windows. It turns out that one of the distutils tests assumes Notepad entries in the registry that aren't actually present unless you run Notepad at least once. I hadn't needed to run it, but then noticed the build failures so ran it just to get the registry populated. ___ 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] raw binary data and 2to3
> data = "GIF89a(..." > > Is there a potentially automated path from where the code is today to > something Python 3 (and 2to3) will like? Not sure how you'll fix these; I personally always provided a b() function that will do the right thing in both 2.x and 3.x. This can get eventually replaced by a b prefix. 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] IDLE as default Python editor (Was: [pygame] Python IDE for windoz)
> Quite an interesting question recently popped up in pygame community > that I'd like to ask to Python developers. > > How many of you use IDLE? I do, sometimes. > What's wrong with it? AFAICT, nothing. >>From my side I like the idea of having default Python editor that is > small, fast, convenient and extensible/embeddable. IDLE is small and > fast, but I feel really uncomfortable with its. The worst thing - I > can't change it. This I cannot understand. I have changed IDLE many times. 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
