Re: [Python-Dev] Proposing PEP 386 for addition
Darren Dale wrote: > On Thu, Dec 10, 2009 at 8:54 AM, Antoine Pitrou wrote: >> Tarek Ziadé gmail.com> writes: >>> Do you have a better suggestion ? I was thinking about StandardVersion >>> but "Standard" >>> doesn't really express what we want to achieve here I think, >> I think StandardVersion is fine. > > I prefer StandardVersion as well. Rational (according to websters.com): Eric's suggestion of NormalizedVersion sounds best to me - it exactly describes the intended role of the class. Cheers, Nick. -- 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
Re: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
Benjamin Peterson wrote: > 2009/12/10 Lennart Regebro : >> On Thu, Dec 10, 2009 at 20:25, Terry Reedy wrote: >>> Since the intent of IGNORE_EXCEPTION_DETAIL is to make doctests immune to >>> implementation version specific changes, it seems to me that extending its >>> technical meaning is required to carry out its intent. >> Would this be considered bugfixy enough to get into 3.1-branch as well >> as 2.7? It really is damn annoying when you try to port doctests to >> Python 3, and it would be great if we wouldn't have to wait for 3.2. > > I think a patch would be helpful before deciding that. Agreed that a patch is needed before deciding, but I support the idea that this be classed as a bug in IGNORE_EXCEPTION_DETAIL - the presence or absence of module information in the printout of the Exception name shouldn't make the test fail. Cheers, Nick. -- 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
Re: [Python-Dev] Proposing PEP 386 for addition
On Fri, Dec 11, 2009 at 6:15 AM, Ben Finney wrote: [..] > > No, the PEP document itself should either contain the questions and > answers, or contain a link to the discussion along with a brief summary > of what it was about and a explicit statement of its outcome. Ok then, I'll add a section summarizing the history of the discussions in that case. Regards Tarek ___ 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] Proposing PEP 386 for addition
On Fri, Dec 11, 2009 at 11:23 AM, Nick Coghlan wrote: > Darren Dale wrote: >> On Thu, Dec 10, 2009 at 8:54 AM, Antoine Pitrou wrote: >>> Tarek Ziadé gmail.com> writes: Do you have a better suggestion ? I was thinking about StandardVersion but "Standard" doesn't really express what we want to achieve here I think, >>> I think StandardVersion is fine. >> >> I prefer StandardVersion as well. Rational (according to websters.com): > > Eric's suggestion of NormalizedVersion sounds best to me - it exactly > describes the intended role of the class. Ok, NormalizedVersion is fine with me, I'll change the doc + code accordingly Regards Tarek ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (12/04/09 - 12/11/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2526 open (+34) / 16775 closed (+11) / 19301 total (+45) Open issues with patches: 1007 Average duration of open issues: 694 days. Median duration of open issues: 450 days. Open Issues Breakdown open 2492 (+34) pending33 ( +0) Issues Created Or Reopened (45) ___ Int/Long: some tests are duplicate and error messages refer to " 12/04/09 CLOSED http://bugs.python.org/issue7435created flox patch Define 'object with assignable attributes' 12/04/09 http://bugs.python.org/issue7436created tjreedy OS X 2.6.4 installer fails on 10.3 with two corrupted file names 12/05/09 http://bugs.python.org/issue7437created ned.deily Allow to use a part of subprocess module during building Python 12/05/09 http://bugs.python.org/issue7438created Arfrever patch, needs review Bug or expected behavior? I cannot tell.12/05/09 CLOSED http://bugs.python.org/issue7439created LambertDW distutils shows incorrect Python version in MSI installers 12/05/09 http://bugs.python.org/issue7440created MarioVilas Py3.1: Fatal Python Error: Py_Initialize...unknown encoding: chc 12/05/09 http://bugs.python.org/issue7441created lieryan decimal.py: format failure with locale specifier 12/05/09 http://bugs.python.org/issue7442created skrah test.support.unlink issue on Windows platform12/05/09 http://bugs.python.org/issue7443created asvetlov patch, needs review Allow for a default method in the JSON decoder 12/05/09 CLOSED http://bugs.python.org/issue7444created dhgoldman urllib2 (and urllib) should raise error for incomplete response 12/05/09 http://bugs.python.org/issue7445created gotgenes http.cookies.BaseCookie (and SimpleCookie) can't be load from di 12/05/09 CLOSED http://bugs.python.org/issue7446created tcourbon Sum() doc and behavior mismatch 12/06/09 http://bugs.python.org/issue7447created tjreedy when piping output between subprocesses some fd is left open blo 12/06/09 http://bugs.python.org/issue7448created nosklo A number tests "crash" if python is compiled --without-threads 12/06/09 http://bugs.python.org/issue7449created r.david.murray patch, easy document that os.chmod accepts an octal digit mode 12/07/09 http://bugs.python.org/issue7450created clutchski improve json decoding performance12/07/09 http://bugs.python.org/issue7451created pitrou patch Invalid mnemonic 'fnstcw'12/07/09 CLOSED http://bugs.python.org/issue7452created srid HPUX 11.00: socketmodule.c -- error 1588: "AI_PASSIVE" undefined 12/08/09 http://bugs.python.org/issue7453created srid
[Python-Dev] Splitting something into two steps produces different behavior from doing it in one fell swoop in Python 2.6.2
While debugging a network algorithm in Python 2.6.2, I encountered
some strange behavior and was wondering whether it has to do with some
sort of code optimization that Python does behind the scenes.
After initialization: defaultdict(, {1: set([1])})
Popping and updating in two steps: defaultdict(, {1: set([1])})
After initialization: defaultdict(, {1: set([1])})
Popping and updating in one step: defaultdict(, {})
import collections
print ''
x = collections.defaultdict(set)
x[1].update([1])
print 'After initialization: %s' % x
items = x.pop(1)
x[1].update(items)
print 'Popping and updating in two steps: %s' % x
print ''
y = collections.defaultdict(set)
y[1].update([1])
print 'After initialization: %s' % y
y[1].update(y.pop(1))
print 'Popping and updating in one step: %s' % y
inOneStepVSTwoSteps.py
Description: Binary data
___
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] Splitting something into two steps produces different behavior from doing it in one fell swoop in Python 2.6.2
Roy Hyunjin Han wrote:
> While debugging a network algorithm in Python 2.6.2, I encountered
> some strange behavior and was wondering whether it has to do with some
> sort of code optimization that Python does behind the scenes.
>
>
>
> After initialization: defaultdict(, {1: set([1])})
> Popping and updating in two steps: defaultdict(, {1: set([1])})
>
> After initialization: defaultdict(, {1: set([1])})
> Popping and updating in one step: defaultdict(, {})
>
>
> import collections
> print ''
> x = collections.defaultdict(set)
> x[1].update([1])
> print 'After initialization: %s' % x
> items = x.pop(1)
> x[1].update(items)
> print 'Popping and updating in two steps: %s' % x
> print ''
> y = collections.defaultdict(set)
> y[1].update([1])
> print 'After initialization: %s' % y
> y[1].update(y.pop(1))
> print 'Popping and updating in one step: %s' % y
>
y[1].update(y.pop(1))
is going to be evaluating y[1] before it evaluates y.pop(1).
Which means that it has the original set returned, which is then removed
by y.pop, and updated.
You probably get the same behavior without using a defaultdict:
y.setdefault(1, set()).update(y.pop(1))
^^- evaluated first
Oh and I should probably give the standard: "This list is for the
development *of* python, not development *with* python."
John
=:->
___
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] Splitting something into two steps produces different behavior from doing it in one fell swoop in Python 2.6.2
John Arbash Meinel wrote:
Roy Hyunjin Han wrote:
While debugging a network algorithm in Python 2.6.2, I encountered
some strange behavior and was wondering whether it has to do with some
sort of code optimization that Python does behind the scenes.
After initialization: defaultdict(, {1: set([1])})
Popping and updating in two steps: defaultdict(, {1: set([1])})
After initialization: defaultdict(, {1: set([1])})
Popping and updating in one step: defaultdict(, {})
import collections
print ''
x = collections.defaultdict(set)
x[1].update([1])
print 'After initialization: %s' % x
items = x.pop(1)
x[1].update(items)
print 'Popping and updating in two steps: %s' % x
print ''
y = collections.defaultdict(set)
y[1].update([1])
print 'After initialization: %s' % y
y[1].update(y.pop(1))
print 'Popping and updating in one step: %s' % y
y[1].update(y.pop(1))
is going to be evaluating y[1] before it evaluates y.pop(1).
Which means that it has the original set returned, which is then removed
by y.pop, and updated.
You probably get the same behavior without using a defaultdict:
y.setdefault(1, set()).update(y.pop(1))
^^- evaluated first
Oh and I should probably give the standard: "This list is for the
development *of* python, not development *with* python."
To me the question was whether Python was behaving correctly; the
behaviour was more subtle than the legendary mutable default argument.
___
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] Unittest/doctest formatting differences in 2.7a1?
On Thu, Dec 10, 2009 at 21:24, Benjamin Peterson wrote: > > 2009/12/10 Lennart Regebro : > > On Thu, Dec 10, 2009 at 20:25, Terry Reedy wrote: > >> Since the intent of IGNORE_EXCEPTION_DETAIL is to make doctests immune to > >> implementation version specific changes, it seems to me that extending its > >> technical meaning is required to carry out its intent. > > > > Would this be considered bugfixy enough to get into 3.1-branch as well > > as 2.7? It really is damn annoying when you try to port doctests to > > Python 3, and it would be great if we wouldn't have to wait for 3.2. > > I think a patch would be helpful before deciding that. Should I start a bug report in the tracker for this? The diff in the code is: # Another chance if they didn't care about the detail. elif self.optionflags & IGNORE_EXCEPTION_DETAIL: -m1 = re.match(r'[^:]*:', example.exc_msg) -m2 = re.match(r'[^:]*:', exc_msg) -if m1 and m2 and check(m1.group(0), m2.group(0), +m1 = re.match(r'(?:[^:]*\.)?([^:]*:)', example.exc_msg) +m2 = re.match(r'(?:[^:]*\.)?([^:]*:)', exc_msg) +if m1 and m2 and check(m1.group(1), m2.group(1), self.optionflags): outcome = SUCCESS But obviously I have patches for both py3k and trunk with tests and updated documentation as well. As you see the diff is pretty simple, it's just a more complex regex. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] Unittest/doctest formatting differences in 2.7a1?
On 9 Dec, 06:09 pm, [email protected] wrote: On 09/12/2009 18:02, [email protected] wrote: On 05:11 pm, [email protected] wrote: On Wed, Dec 9, 2009 at 17:34, Michael Foord wrote: Can you be more specific? Only with an insane amount of work. I'll hold that off for a while. I don't know if this is related at all (and I guess we won't until Lennart can be more specific :), but here are some Twisted unit test failures which are probably due to unittest changes in 2.7: === [FAIL]: twisted.trial.test.test_loader.LoaderTest.test_sortCases Traceback (most recent call last): File "/home/buildslave/pybot/trunk.glass-x86/build/Twisted/twisted/trial/test/test_loader.py", line 167, in test_sortCases [test._testMethodName for test in suite._tests]) twisted.trial.unittest.FailTest: not equal: a = ['test_b', 'test_c', 'test_a'] b = ['test_c', 'test_b', 'test_a'] Is the order significant? Can you just compare sorted versions of the lists instead? If the order *is* significant I would be interested to know which change caused this. It looks like a change to shortDescription may be responsible for all the failures mentioned here. The order *is* significant (it's a test for how tests are ordered...). The sorting code (which wasn't super awesome, I'll admit) it uses was broken by the change in the return value of shortDescription, something which is much more obvious in some of the other failures. [snip] a = 'skip1 (twisted.trial.test.test_tests.SkippingTests)' b = 'skip1' These two test failures are due to the change in repr of something I guess? Is a or b the original output? b is the original, a is the produced value. Here's a simpler example: Python 2.6.4 (r264:75706, Nov 2 2009, 14:38:03) [GCC 4.4.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. from twisted.test.test_abstract import AddressTests AddressTests('test_decimalDotted').shortDescription() 'test_decimalDotted' Python 2.7a0 (trunk:76325M, Nov 16 2009, 09:50:40) [GCC 4.4.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. from twisted.test.test_abstract import AddressTests AddressTests('test_decimalDotted').shortDescription() 'test_decimalDotted (twisted.test.test_abstract.AddressTests)' Aside from compatibility issues, this seems like a not-too-ideal change in behavior for a method named "shortDescription", at least to me. Going out on a limb, I'll guess that it was made in order to provide a different user-facing experience in the stdlib's test runner. If that's right, then I think it would make sense to revert shortDescription back to the previous behavior and either introduce a new method which returns this string or just put the logic all into the display code instead. I'm not opposed to the improvement of unittest (or any part of Python). Perhaps more of the improvements can be provided in new APIs rather than by changing the behavior of existing APIs, though. Well, introducing lots of new APIs has its own problems of course. It seems to me that it typically has fewer problems. Hearing about difficulties changes cause is good though (the reason for alphas I guess) and if it is possible to work out why things are broken then maybe we can still have the new functionality without the breakage. Of course. Also, I should have pointed this out in my previous email, this information about failures is always easily available, at least for Twisted (and at most for any project interested in participating in the project), on the community buildbots page: http://www.python.org/dev/buildbot/community/trunk/ So anyone who cares to can check to see if their changes have broken things right away, instead of only finding out 6 or 12 or 18 months later. :) The problem with Lennart's report is that it is just "things are broken" without much clue. I am sympathetic to this (working out *exactly* what is broken in someone else's code can be a painful chore) but I'm not sure what can be done about it without more detail. Certainly. Perhaps Zope would like to add something to the community builders page. Thanks, Jean-Paul ___ 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] Unittest/doctest formatting differences in 2.7a1?
On Fri, Dec 11, 2009 at 21:36, wrote: > Certainly. Perhaps Zope would like to add something to the community > builders page. The Zope Component Architecture would be nice to test like that. Much of the rest of Zope needs massaging between python versions, so that may not be useful. http://www.python.org/dev/buildbot/community/trunk/ So anyone who cares to can check to see if their changes have broken things right away, instead of only finding out 6 or 12 or 18 months later. :) Cc:ing zope-dev for opinions. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] Splitting something into two steps produces different behavior from doing it in one fell swoop in Python 2.6.2
On Fri, Dec 11, 2009 at 2:43 PM, MRAB wrote:
> John Arbash Meinel wrote:
>>
>> Roy Hyunjin Han wrote:
>>>
>>> While debugging a network algorithm in Python 2.6.2, I encountered
>>> some strange behavior and was wondering whether it has to do with some
>>> sort of code optimization that Python does behind the scenes.
>>>
>>>
>>>
>>> After initialization: defaultdict(, {1: set([1])})
>>> Popping and updating in two steps: defaultdict(, {1:
>>> set([1])})
>>>
>>> After initialization: defaultdict(, {1: set([1])})
>>> Popping and updating in one step: defaultdict(, {})
>>>
>>>
>>> import collections
>>> print ''
>>> x = collections.defaultdict(set)
>>> x[1].update([1])
>>> print 'After initialization: %s' % x
>>> items = x.pop(1)
>>> x[1].update(items)
>>> print 'Popping and updating in two steps: %s' % x
>>> print ''
>>> y = collections.defaultdict(set)
>>> y[1].update([1])
>>> print 'After initialization: %s' % y
>>> y[1].update(y.pop(1))
>>> print 'Popping and updating in one step: %s' % y
>>>
>>
>> y[1].update(y.pop(1))
>>
>> is going to be evaluating y[1] before it evaluates y.pop(1).
>> Which means that it has the original set returned, which is then removed
>> by y.pop, and updated.
>>
>> You probably get the same behavior without using a defaultdict:
>> y.setdefault(1, set()).update(y.pop(1))
>> ^^- evaluated first
>>
>>
>> Oh and I should probably give the standard: "This list is for the
>> development *of* python, not development *with* python."
>>
> To me the question was whether Python was behaving correctly; the
> behaviour was more subtle than the legendary mutable default argument.
Thanks, John and MRAB. I was pointing it out on this list because I
felt like it was counterintuitive and that the result should be the
same whether the developer decides to do it in two steps or in one
step.
___
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] Unittest/doctest formatting differences in 2.7a1?
Lennart Regebro wrote: > On Thu, Dec 10, 2009 at 21:24, Benjamin Peterson wrote: >> 2009/12/10 Lennart Regebro : >>> On Thu, Dec 10, 2009 at 20:25, Terry Reedy wrote: Since the intent of IGNORE_EXCEPTION_DETAIL is to make doctests immune to implementation version specific changes, it seems to me that extending its technical meaning is required to carry out its intent. >>> Would this be considered bugfixy enough to get into 3.1-branch as well >>> as 2.7? It really is damn annoying when you try to port doctests to >>> Python 3, and it would be great if we wouldn't have to wait for 3.2. >> I think a patch would be helpful before deciding that. > > Should I start a bug report in the tracker for this? Yep. > The diff in the code is: > > # Another chance if they didn't care about the detail. > elif self.optionflags & IGNORE_EXCEPTION_DETAIL: > -m1 = re.match(r'[^:]*:', example.exc_msg) > -m2 = re.match(r'[^:]*:', exc_msg) > -if m1 and m2 and check(m1.group(0), m2.group(0), > +m1 = re.match(r'(?:[^:]*\.)?([^:]*:)', example.exc_msg) > +m2 = re.match(r'(?:[^:]*\.)?([^:]*:)', exc_msg) > +if m1 and m2 and check(m1.group(1), m2.group(1), > self.optionflags): > outcome = SUCCESS > > But obviously I have patches for both py3k and trunk with tests and > updated documentation as well. > As you see the diff is pretty simple, it's just a more complex regex. Looks reasonable to me, although any backport to existing branches will be Benjamin's call for 3.1 and Barry's for 2.6 (as the respective release managers). Cheers, Nick. -- 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
Re: [Python-Dev] Splitting something into two steps produces different behavior from doing it in one fell swoop in Python 2.6.2
Roy Hyunjin Han wrote: > On Fri, Dec 11, 2009 at 2:43 PM, MRAB wrote: >> John Arbash Meinel wrote: >>> y[1].update(y.pop(1)) >>> >>> is going to be evaluating y[1] before it evaluates y.pop(1). >>> Which means that it has the original set returned, which is then removed >>> by y.pop, and updated. >> To me the question was whether Python was behaving correctly; the >> behaviour was more subtle than the legendary mutable default argument. > > Thanks, John and MRAB. I was pointing it out on this list because I > felt like it was counterintuitive and that the result should be the > same whether the developer decides to do it in two steps or in one > step. It follows the standard left-to-right evaluation order within an expression: () (i.e. a function call always determines which function is going to be called before determining any arguments to be passed) Splitting it into two lines then clearly changes the evaluation order: temp = (temp) I'm not sure what behaviour could be suggested as being more intuitive - the problem in this case arose due to both referencing and mutating the same object in a single statement, which is always going to be problematic from an ordering point of view, since it depends on subtle details of statement definitions that people often won't know. Better to split the mutation and the reference into separate statements so the intended order is clear regardless of how well the reader knows the subtleties of Python's evaluation order. Cheers, Nick. -- 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
Re: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: > On Fri, Dec 11, 2009 at 21:36, wrote: >> Certainly. Perhaps Zope would like to add something to the community >> builders page. > > The Zope Component Architecture would be nice to test like that. Much > of the rest of Zope needs massaging between python versions, so that > may not be useful. > > http://www.python.org/dev/buildbot/community/trunk/ > > So anyone who cares to can check to see if their changes have broken > things right away, instead of only finding out 6 or 12 or 18 months > later. :) > > Cc:ing zope-dev for opinions. +1 in general to the idea: we should be able to put together a "buildcompat"-style buildout which would be autoamatable under buildbot. Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksjD80ACgkQ+gerLs4ltQ5IggCeOzMSYJ3rYAXNdkj1f/03gkfJ usAAn2gYe8DN550roU+VXl8cHSOyI6uY =f1Ww -END 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
