Re: [Python-Dev] Undocumenting test.support in 3.x (was Py3k DeprecationWarning in stdlib)
On Thu, Jun 26, 2008 at 12:27 AM, Brett Cannon <[EMAIL PROTECTED]> wrote: > Right, but I would think all core developers know about test.support > and are capable of reading the code and docstring. Docstrings don't help for things other than Modules, Classes and Functions. So, for example, are constants like FUZZ intended to be part of the external API provided by the module or not? Also, there are already a fair number of functions in test_support that don't have docstrings. Are these intended to be part of the API? Obviously one can grep around the existing tests to see what they do, but then one ends up perpetuating any errors others have made. While one could possibly attempt to make a case for "all core developers know" [1] it certainly isn't true that "all future core developers know" [2] or that "all people who could put patches into the issue tracker know" [3]. [1] Although personally I would bet against it until proven -- especially given a sensible definition of "core developer" to mean, in this case, anyone with the right to commit tests to the repository. [2] Since many of these future developers probably don't even use Python yet. [3] And we do want patches to issues to include tests, right? ___ 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-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
From: "Guido van Rossum" <[EMAIL PROTECTED]> I don't care about the details of the patch until we have agreement about which form the feature should take. We don't have that agreement yet. Updated to the patch to address everyone's review comments: http://bugs.python.org/file10742/float8.diff * Alexander Belopolsky requested exponential notation instead of potentially very long strings of bits. Done * Alexander Belopolsky requested true mathematical radix 2 representation of a float rather than its 64-bit memory layout. Done * Antoine Pitrou requested that hex() and oct() be supported as well as bin(). Terry J. Reedy also requested support for hex(). Done. * Alexander Belopolsky and Alexandre Vassalotti requested that the output be a two-way street -- something that can be round-tripped through eval(). Done. * Amaury Forgeot d'Arc requested that the implementation not manipulate C strings inplace. Fixed -- used PyUnicode_FromFormat() instead. * Amaury Forgeot d'Arc requested that tests should check if negative numbers have the same representation as their absolute value. Done. * Mark Dickinson requested sign preserving output for bin(-0.0). We couldn't find a clean way to do this without a special cased output format. * Mark Dickinson reviewed the NaN/Inf handling. Done. * Eric Smith requested that the routine be attached to _PyFloat_to_base() instead of attaching to __bin__, __oct__, and __hex__. Done. * Guido requested that the docs be updated. Done. * Guido requested that the globally visible C API function name be prefixed with _Py. Done. * Mark Dickinson requested normalizing output to start with a 1 so that nearby values have similar reprs. Done. 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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
On 26/06/2008, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > From: "Guido van Rossum" <[EMAIL PROTECTED]> > > I don't care about the details of the patch until we have agreement > > about which form the feature should take. We don't have that agreement > > yet. > > > > Updated to the patch to address everyone's review comments: > http://bugs.python.org/file10742/float8.diff Just as a contrary point, I'm not particularly keen on the output format (which takes the form '0b1 * 2.0 ** 0' as far as I can see), and I'm definitely not keen on the fact that it's overloaded on the hex/bin/oct builtins. Can't it be a separate function? If it is, I don't much care about the output format (as I have no particular need for the feature) but would it not be better if it were machine-parseable, rather than executable? 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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
Actually, after saying I was opposed to __bin__ in 2.6, I said: "Instead, I think the approach used in 3.0 (r64451) should be used instead. That is, if this feature exist at all. I'm -0 on adding bin(), etc. to floats." My last sentence is a little unclear. I meant I'm -0 on adding floats as arguments to bin(), oct(), and hex(). Primarily because a) it's not extensible in 3.0, and b) I find it surprising, in that I'd expect those functions to throw an error for non-integral types (that is, those not having __index__). I think adding a "float_as_binary_expression()" (with a better name) in some module would get the functionality you seek. What is gained by adding this to bin() and friends? Raymond Hettinger wrote: From: "Guido van Rossum" <[EMAIL PROTECTED]> I don't care about the details of the patch until we have agreement about which form the feature should take. We don't have that agreement yet. Updated to the patch to address everyone's review comments: http://bugs.python.org/file10742/float8.diff * Alexander Belopolsky requested exponential notation instead of potentially very long strings of bits. Done * Alexander Belopolsky requested true mathematical radix 2 representation of a float rather than its 64-bit memory layout. Done * Antoine Pitrou requested that hex() and oct() be supported as well as bin(). Terry J. Reedy also requested support for hex(). Done. * Alexander Belopolsky and Alexandre Vassalotti requested that the output be a two-way street -- something that can be round-tripped through eval(). Done. * Amaury Forgeot d'Arc requested that the implementation not manipulate C strings inplace. Fixed -- used PyUnicode_FromFormat() instead. * Amaury Forgeot d'Arc requested that tests should check if negative numbers have the same representation as their absolute value. Done. * Mark Dickinson requested sign preserving output for bin(-0.0). We couldn't find a clean way to do this without a special cased output format. * Mark Dickinson reviewed the NaN/Inf handling. Done. * Eric Smith requested that the routine be attached to _PyFloat_to_base() instead of attaching to __bin__, __oct__, and __hex__. Done. * Guido requested that the docs be updated. Done. * Guido requested that the globally visible C API function name be prefixed with _Py. Done. * Mark Dickinson requested normalizing output to start with a 1 so that nearby values have similar reprs. Done. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/eric%2Bpython-dev%40trueblade.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
Re: [Python-Dev] Undocumenting test.support in 3.x (was Py3k DeprecationWarning in stdlib)
On Thu, Jun 26, 2008 at 3:58 AM, Simon Cross <[EMAIL PROTECTED]> wrote: > > [1] Although personally I would bet against it until proven -- > especially given a sensible definition of "core developer" to mean, in > this case, anyone with the right to commit tests to the repository. > [2] Since many of these future developers probably don't even use Python yet. > [3] And we do want patches to issues to include tests, right? See my above message. I don't think we need to worry about the docs part of "undocumented." All I mean by undocumented is that the API is not guaranteed throughout versions, and test.support really should only be used for core tests. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ 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-checkins] r64424 - in python /trunk:Include/object.hLib/test/test_sys.py Mi sc/NEWSObjects/intobject.cObjects/longobject.c Obj ects/typeobject.cPython/bltinmodule.c
Raymond Hettinger rcn.com> writes: > > * Antoine Pitrou requested that hex() and oct() be supported as well as bin(). Just to qualify this, I said that if bin() were to gain float support, the same should probably be done for hex() and oct(). That doesn't mean I'm in favor of bin() support for floats. 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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
Would you mind reading the rest of *this* thread on python-dev and respond to the discussion about the design of the feature? On Thu, Jun 26, 2008 at 4:24 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > From: "Guido van Rossum" <[EMAIL PROTECTED]> >> >> I don't care about the details of the patch until we have agreement >> about which form the feature should take. We don't have that agreement >> yet. > > Updated to the patch to address everyone's review comments: > http://bugs.python.org/file10742/float8.diff > > * Alexander Belopolsky requested exponential notation instead of potentially > very long strings of bits. Done > > * Alexander Belopolsky requested true mathematical radix 2 representation > of a float rather than its 64-bit memory layout. Done > > * Antoine Pitrou requested that hex() and oct() be supported as well as > bin(). Terry J. Reedy also requested support for hex(). Done. > > * Alexander Belopolsky and Alexandre Vassalotti requested that the output be > a two-way street -- something that can be round-tripped through eval(). > Done. > > * Amaury Forgeot d'Arc requested that the implementation not manipulate C > strings inplace. Fixed -- used PyUnicode_FromFormat() instead. > > * Amaury Forgeot d'Arc requested that tests should check if negative numbers > have the same representation as their absolute value. Done. > > * Mark Dickinson requested sign preserving output for bin(-0.0). We > couldn't find a clean way to do this without a special cased output format. > > * Mark Dickinson reviewed the NaN/Inf handling. Done. > > * Eric Smith requested that the routine be attached to _PyFloat_to_base() > instead of attaching to __bin__, __oct__, and __hex__. Done. > > * Guido requested that the docs be updated. Done. > > * Guido requested that the globally visible C API function name be prefixed > with _Py. Done. > > * Mark Dickinson requested normalizing output to start with a 1 so that > nearby values have similar reprs. Done. > > > Raymond > -- --Guido van Rossum (home page: http://www.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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
Just as a contrary point, I'm not particularly keen on the output format (which takes the form '0b1 * 2.0 ** 0' as far as I can see), That format was requested by everyone else on the tracker discussion. What I originally wanted was something like 0b11.0101. But that didn't round-trip through eval, it didn't match the style used in the numerical papers referenced by Terry Reedy, and it didn't scale well with inputs like 1.1E+100. and I'm definitely not keen on the fact that it's overloaded on the hex/bin/oct builtins. Can't it be a separate function? Simplicity. bin/oct/hex have the job of giving alternate base representations for numbers. Nothing is gained by adding a duplicate set of functions in the math module for float inputs. would it not be better if it were machine-parseable, rather than executable? We already have struct.pack for machine-parseable output. This is supposed to be human readable as well as providing an exact, platform indepent way of specifying a particular float value (something that's useful in testing algorithms like that in math.sum()). 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] Py3k DeprecationWarning in stdlib
Andrew Bennetts wrote: Brett Cannon wrote: On Wed, Jun 25, 2008 at 6:08 AM, Andrew Bennetts [...] Should I file a bug for this? If you want, but Benjamin plans to undocument this for users along with all other test.support stuff (which I agree with). Most of the APIs in test.support were just quickly written and have not necessarily been thought through in order to make sure that the APIs makes sense (like in this case). Ok, then we're back to there being no supported way to write tests that need to intercept warnings. Twisted has already suffered from this (JP reports that Twisted's assertWarns is broken in 2.6), and I doubt it's alone. So I guess I am filing a bug after all... :) Yeah - Brett's correct that everything under "test.test_support" should really be formally undocumented. It's mostly a place for code that reflects "things we do a lot in our unit tests and are tired of repeating" rather than "this is a good API that we want to support forever and encourage other people to use". However, if other folks turn out to have similar needs, then it may be possible to add something to unittest to support it. However, given that the beta deadline has already passed, you may need to use similar hackery to that used by catch_warning and replace warnings.showwarning with a test function that saves the raised exception (it also wouldn't be hard to enhance it a bit to handle more than a single warning). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] Undocumenting test.support in 3.x (was Py3k DeprecationWarning in stdlib)
Benjamin Peterson wrote: On Wed, Jun 25, 2008 at 4:00 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: I'm a little worried about making stuff undocumented that every core developer needs to use -- everyone writing tests needs to continue to use test_support (now test.support?). I imagine people writing unit test suites for 3rd party libraries might want to use its services too. I think undocumented is a little unspecific here. What I mean is "reserved for core Python tests and no promise is made to retain compatibility." Of course, we would keep docs for them (perhaps in Lib/test/README), so new core developers could write their tests. Alternatively, we could just leave them out of the docs table of contents, and stick a big warning at the top saying that these are internal APIs and subject to change without warning between releases. (This discussion actually argues somewhat in favour of having _test as the top-level package name for the regression test suite - after all, we make *zero* promises about keeping the API of any of the test modules the same from release to release, so we should really be using the standard leading underscore convention to flag internal implementation details that are not really intended for use by third parties) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
On Thu, Jun 26, 2008 at 5:50 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> Just as a contrary point, I'm not particularly keen on the output >> format (which takes the form '0b1 * 2.0 ** 0' as far as I can see), > > That format was requested by everyone else on the tracker > discussion. What I originally wanted was something like 0b11.0101. > But that didn't round-trip through eval, it didn't match the style used in > the numerical papers referenced by Terry Reedy, and it didn't scale > well with inputs like 1.1E+100. > >> and I'm definitely not keen on the fact that it's overloaded on the >> hex/bin/oct builtins. >> >> Can't it be a separate function? > > Simplicity. bin/oct/hex have the job of giving alternate base > representations for numbers. > Nothing is gained by adding a duplicate set of functions in the math module > for float inputs. I disagree, and others here have disagreed too. We made a consicous decision to *remove* the overloading of hex/oct/bin via __hex__/__oct__/__bin__ in 3.0, in order to simplify these functions, which only work for integers, not for any other style of numbers. If bin(3.4) works, why not bin() of a Fraction, or of a complex number? Or for that matter, why not hex() of a string? All these have some use case. But is that use case important enough to put it in the bin()/hex()/oct() built-in functions? Why not hex() of a dictionary? Where does it end? We drew a line in the sand -- these are only for ints. >> would >> it not be better if it were machine-parseable, rather than executable? > > We already have struct.pack for machine-parseable output. > This is supposed to be human readable as well as providing > an exact, platform indepent way of specifying a particular > float value (something that's useful in testing algorithms like that in > math.sum()). The only use cases you bring up appear to be in testing and education. This is not a strong enough motivation for adding a wart to the bin/oct/hex builtins. I'm sure you can write the same thing in pure Python -- wouldn't that be good enough for testing? And if you then put it somewhere in a module in the stdlib, wouldn't that be good enough for education? There's a strong movement for keeping the language small and clean. Adding more overloaded functionality to built-in functions goes counter to that ideal. A new stdlib function causes no overhead to the *language* definition (and built-ins *are* part of the language). -- --Guido van Rossum (home page: http://www.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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
Would you mind reading the rest of *this* thread on python-dev and respond to the discussion about the design of the feature? The last four entries were from this thread. I don't know what else you want me to do. I can update the patch as people make suggestions. That's pretty much it. I recapped the earlier discussion from the tracker so the participants in this thread would be aware of the requests that were made there and why. I originally wanted a different output format but it evolved to the one that's there now to meet the various needs of the posters. This is important background for someone just joining the thread and thinking a different output format would be better. There's a part of this thread that says basically, "fine, but stick it somewhere else." To me, it doesn't make any sense at all to create a parallel set of functions in the math module. To convert a number to binary, it makes sense to use the bin() function. I don't understand this notion that bin() is a sacred cow of intergerdom and would philosophically corrupt if it handled floats also. 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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
Raymond Hettinger wrote: and I'm definitely not keen on the fact that it's overloaded on the hex/bin/oct builtins. Can't it be a separate function? Simplicity. bin/oct/hex have the job of giving alternate base representations for numbers. Nothing is gained by adding a duplicate set of functions in the math module for float inputs. I'd place additional requirements on using bin/oct/hex for this: 1. The new feature must be available to floating point types other than float (such as Decimal) in both 2.6 and 3.0 (keeping in mind that 3.0 does not support __bin__, __hex__, or __oct__ methods - it uses only __index__ to implement bin(), hex() and oct() 2. Other classes (such as Decimal) should be able to leverage the formatting functionality provided for floats. If it was just a new method on float objects or a new function in the math module, neither of those additional requirements would apply - I would be completely fine with the function only working for actual float objects. However, in either case, I think this also runs afoul of the "we're in beta" argument - yes, it's a nice feature, but I don't think it's one that will cause any great dramas if users don't get their hands on it until 2.7/3.1. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
Raymond Hettinger wrote: There's a part of this thread that says basically, "fine, but stick it somewhere else." To me, it doesn't make any sense at all to create a parallel set of functions in the math module. To convert a number to binary, it makes sense to use the bin() function. I don't understand this notion that bin() is a sacred cow of intergerdom and would philosophically corrupt if it handled floats also. It isn't the extension to something other than integers that bothers me, it's the extension to floats in a way that can't be easily supported for other types such as decimal.Decimal and fractions.Fraction. Well, that and the beta deadline (we have to draw the line somewhere, or we'll be stuck in an eternal spiral of "just one more feature") Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] Py3k DeprecationWarning in stdlib
On Thu, 26 Jun 2008 23:56:23 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
[snip]
Ok, then we're back to there being no supported way to write tests that
need to
intercept warnings. Twisted has already suffered from this (JP reports
that
Twisted's assertWarns is broken in 2.6), and I doubt it's alone.
So I guess I am filing a bug after all... :)
Yeah - Brett's correct that everything under "test.test_support" should
really be formally undocumented. It's mostly a place for code that reflects
"things we do a lot in our unit tests and are tired of repeating" rather
than "this is a good API that we want to support forever and encourage other
people to use".
However, if other folks turn out to have similar needs, then it may be
possible to add something to unittest to support it. However, given that the
beta deadline has already passed, you may need to use similar hackery to
that used by catch_warning and replace warnings.showwarning with a test
function that saves the raised exception (it also wouldn't be hard to
enhance it a bit to handle more than a single warning).
We don't use showwarning because in order to reliably catch warnings that
way, it's necessary to rely on even more private implementation details of
the warning system.
Consider this:
from warnings import warn
from test.test_support import catch_warning
def f():
warn("foo")
def test():
with catch_warning() as w:
f()
assert str(w.message) == "foo", "%r != %r" % (w.message, "foo")
test()
test()
The first assertion passes (by the way, I don't understand why w.message
isn't the message passed to warn, but is instead an instance of UserWarning)
but the second assertion fails. A more subtle example might include two
functions, the first of which is deprecated and called by the second, and
one test for each of them. Now the test for the warning will only pass if
it runs before the other test; if they accidentally run in the other order,
you won't see the warning, so as far as I can tell, you can't reliably write
a unit test for warnings using catch_warning.
The real problem with testing many uses of the warning system is that it
doesn't expose enough public APIs for this to be possible. You *have*
to use APIs which are, apparently, private (such as warn_explicit).
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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
Raymond Hettinger wrote:
FYI, I had already updated the patch to incorporate your suggestion.
It checks __index__ first and then __float__ if index doesn't exist.
The result makes it work with Decimal inputs.
Only sort of - the domain of the output is then constrained by what the
builtin float type can represent, which strikes me as fairly
inappropriate for what should be a lossless display operation (both
fractions.Fraction and decimal.Decimal can represent a lot of numbers
that float can't deal with properly). To use the old faithful example of
this, given:
>>> float(Decimal("1.1"))
1.1001
what happens for bin(Decimal("1.1")) with the patch version that uses
__float__?
As I've said elsewhere in this thread, I'm certainly not averse to the
basic idea of letting bin/oct/hex handle rational numbers as well as
integers, I just don't see it as something we have to have in the
current release cycle, and nor do I see it really working properly
without adding a __rational__ special method that returns a
numerator/denominator 2-tuple (which would obviously require a PEP).
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.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-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
Eric Smith wrote: Actually, after saying I was opposed to __bin__ in 2.6, I said: "Instead, I think the approach used in 3.0 (r64451) should be used instead. That is, if this feature exist at all. I'm -0 on adding bin(), etc. to floats." My last sentence is a little unclear. I meant I'm -0 on adding floats as arguments to bin(), oct(), and hex(). Primarily because a) it's not extensible in 3.0, and b) I find it surprising, in that I'd expect those functions to throw an error for non-integral types (that is, those not having __index__). I think adding a "float_as_binary_expression()" (with a better name) in some module would get the functionality you seek. What is gained by adding this to bin() and friends? And to clarify myself, yet again (from private email with Raymond): I actually think it's a useful feature, just not in bin(). I'm sure it will land somewhere, and I'm also sure I'll use it, at least from the interactive prompt. And if bin() were generally extensible for all types, I wouldn't really even care all that much if this feature landed in bin(). But 3.0 is going in the opposite direction, which is what much of my concern is based on, and why I commented at the outset on the 2.6 approach differing from the 3.0 approach. Eric. ___ 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] Py3k DeprecationWarning in stdlib
On Thu, Jun 26, 2008 at 6:56 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Andrew Bennetts wrote: >> >> Brett Cannon wrote: >>> >>> On Wed, Jun 25, 2008 at 6:08 AM, Andrew Bennetts >> >> [...] Should I file a bug for this? >>> If you want, but Benjamin plans to undocument this for users along >>> with all other test.support stuff (which I agree with). Most of the >>> APIs in test.support were just quickly written and have not >>> necessarily been thought through in order to make sure that the APIs >>> makes sense (like in this case). >> >> Ok, then we're back to there being no supported way to write tests that >> need to >> intercept warnings. Twisted has already suffered from this (JP reports >> that >> Twisted's assertWarns is broken in 2.6), and I doubt it's alone. >> >> So I guess I am filing a bug after all... :) > > Yeah - Brett's correct that everything under "test.test_support" should > really be formally undocumented. It's mostly a place for code that reflects > "things we do a lot in our unit tests and are tired of repeating" rather > than "this is a good API that we want to support forever and encourage other > people to use". I still have a big problem with this attitude. If it's valuable enough to share between our tests, it should be properly written for reuse and documented. A collection of hacks remains a collection of hacks. We can do better. > However, if other folks turn out to have similar needs, then it may be > possible to add something to unittest to support it. However, given that the > beta deadline has already passed, you may need to use similar hackery to > that used by catch_warning and replace warnings.showwarning with a test > function that saves the raised exception (it also wouldn't be hard to > enhance it a bit to handle more than a single warning). I don't think the beta should be used as an argument to prevent refactoring and documenting code. I think Andrew's complaint is justified and should be addressed. I don't expect the test suite to remain unchanged while we're in beta anyways... -- --Guido van Rossum (home page: http://www.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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 26, 2008, at 10:40 AM, Nick Coghlan wrote: Well, that and the beta deadline (we have to draw the line somewhere, or we'll be stuck in an eternal spiral of "just one more feature") Guido wanted to get the beta out when we did exactly so we could draw this line in the sand. I'd much rather people be spending time getting what features we do have tested, stabilized, bug fixed, and turning the buildbots green across the board. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSGOx6HEjvBPtnXfVAQK/IwP+MM75Kw0pMtzQ0wND51D6Gkyx/anr6xOf uLQ41AhcPd//XDTfMQOO9DYsks1sxt8UnDtajyAFGKK9tZmymhwttplJpBdFDSM7 4km2tV9TZZJQUI/VUwV/d6IT80xfdct6c+lkOjeOl2KMnkPEuu+AoLnG0Me8FKiX heC8FnyXut4= =pG60 -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
Re: [Python-Dev] Py3k DeprecationWarning in stdlib
Jean-Paul Calderone wrote: The first assertion passes (by the way, I don't understand why w.message isn't the message passed to warn, but is instead an instance of UserWarning) but the second assertion fails. See Brett's comment elsewhere in this thread about the level of thought (or lack thereof) that went into the design of some of the test_support APIs (including catch_warning). A more subtle example might include two functions, the first of which is deprecated and called by the second, and one test for each of them. Now the test for the warning will only pass if it runs before the other test; if they accidentally run in the other order, you won't see the warning, so as far as I can tell, you can't reliably write a unit test for warnings using catch_warning. Yeah, the Python regression tests actually cheat quite a bit when it comes to testing warnings - several of the tests clear the warning cache just in case the warning has already been triggered by other code. I suspect what some of those tests *should* be doing (aside from those testing the warning module itself) is configuring the warning system to convert the relevant warnings to exceptions, then catching the resulting exception. The real problem with testing many uses of the warning system is that it doesn't expose enough public APIs for this to be possible. You *have* to use APIs which are, apparently, private (such as warn_explicit). Hmm, I think the bigger problem is that there is no documented way to save the warnings filter and restore it to a previous state - the 'filters' attribute (which holds the actual list of filters) isn't documented and isn't included in __all__. This makes it hard to write an officially supported test that fiddles with the warning settings then puts them back the way they were. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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
[Python-Dev] Community buildbots and Python release quality metrics
Today on planetpython.org, Doug Hellman announced the June issue of Python magazine. The cover story this month is about Pybots, "the fantastic automation system that has been put in place to make sure new releases of Python software are as robust and stable as possible". Last week, there was a "beta" release of Python which, according to the community buildbots, cannot run any existing python software. Normally I'd be complaining here about Twisted, but in fact Twisted is doing relatively well right now; only 80 failing tests. Django apparently cannot even be imported. The community buildbots have been in a broken state for months now[1]. I've been restraining myself from whinging about this, but now that it's getting close to release, it's time to get these into shape, or it's time to get rid of them. There are a few separate issues here. One is, to what extent should Python actually be compatible between releases? There's not much point in saying "this release is compatible with python 2.5" if all python 2.5 programs need to be modified in order to run on python 2.6. Of course, it's quite likely that there are some 3rd-party Python programs that continue to work, but python.org provides links to 2 projects that don't and none that do. Another way to phrase this question is, "whose responsibility is it to make Python 2.5 programs run on Python 2.6"? Or, "what happens when the core team finds out that a change they have made has broken some python software 'in the wild'"? Here are a couple of ways to answer these questions: 1) It's the python core team's responsibility. There should be Python buildbots for lots of different projects and they should all be green before the code can be considered [one of: allowed in trunk, alpha, beta, RC]. 2) It's the python core team's responsibility as long as the major projects are using public APIs. The code should not be considered [alpha, beta, RC] if there are any known breakages in public APIs. 3) It's only the python core team's responsibility to notify projects of incompatible changes of which they are aware, which may occur in public or private APIs. Major projects with breakages will be given a grace period before a [beta, RC, final] to release a forward-compatible version. 4) The status quo: every new Python release can (and will, at least speaking in terms of 2.6) break lots of popular software, with no warning aside from the beta period. There are no guarantees. For obvious reasons, I'd prefer #1, but any of the above is better than #4. I don't think #4 is an intentional choice, either; I think it's the result of there being no clear consequence for community buildbots failing. Or, for that matter, of core buildbots failing. Investigating the history is tricky (I see a bunch of emails from Barry here, but I'm not sure which is the final state) but I believe the beta went out with a bunch of buildbots offline or failing. A related but independent issue is: should the community buildbots continue to exist? An automated test is only as good as the consequences of its failure. As it stands, the community buildbots seem to be nothing but an embarrassment. I don't mean this to slam Grig, or the Python team - I mean, literally, if there is no consequence of their failure then the only use I can see for the data the buildbots currently provide (i.e. months and months of failures) is to embarrass the Python core developers. python.org's purpose should not be to provide negative press for Python ;), so if this continues to be the case, they probably shouldn't be linked. This isn't just an issue with changes to Python breaking stuff; the pybots' configuration is apparently not well maintained, since the buildbots which say "2.5" aren't passing either, and that's not a problem with the code, it's just that the slaves are actually running against [EMAIL PROTECTED] Ultimately these tools only exist to ensure the quality of Python releases. The really critical question here is, what does it mean to have a Python release that is high-quality? There are some obvious things: it shouldn't crash, it should conform to its own documentation. Personally I think "it passes all of its own tests" and "it runs existing Python code" are important metrics too, but the most important thing I'm trying to get across here is that there should be a clear understanding of which goals the release / QA / buildbot / test process is trying to accomplish. For me, personally, it really needs to be clear when I can say "you guys screwed up and broke stuff", and when I just have to suck it up and deal with the consequences of a new version of Python in Twisted. It's definitely bad for all of us if the result is that new releases of Python just break everything. Users don't care where the responsibility lies, they just know that stuff doesn't work, so we should decide on a process which allows
Re: [Python-Dev] Undocumenting test.support in 3.x (was Py3k DeprecationWarning in stdlib)
On Thu, Jun 26, 2008 at 7:08 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Benjamin Peterson wrote: >> >> On Wed, Jun 25, 2008 at 4:00 PM, Guido van Rossum <[EMAIL PROTECTED]> >> wrote: >>> >>> I'm a little worried about making stuff undocumented that every core >>> developer needs to use -- everyone writing tests needs to continue to >>> use test_support (now test.support?). I imagine people writing unit >>> test suites for 3rd party libraries might want to use its services >>> too. >> >> I think undocumented is a little unspecific here. What I mean is >> "reserved for core Python tests and no promise is made to retain >> compatibility." Of course, we would keep docs for them (perhaps in >> Lib/test/README), so new core developers could write their tests. > > Alternatively, we could just leave them out of the docs table of contents, > and stick a big warning at the top saying that these are internal APIs and > subject to change without warning between releases. > > (This discussion actually argues somewhat in favour of having _test as the > top-level package name for the regression test suite - after all, we make > *zero* promises about keeping the API of any of the test modules the same > from release to release, so we should really be using the standard leading > underscore convention to flag internal implementation details that are not > really intended for use by third parties) That would also remove the problem users encounter from time to time with module files named "test.py". But I think we should think about this more. I don't think anyone expects the code inside any particular test_foo.py to have a stable public interface. But quite a bit of the test support infrastructure is reused by third party test frameworks. I think we should acknowledge and support such reuse. -- --Guido van Rossum (home page: http://www.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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
Barry Warsaw wrote: On Jun 26, 2008, at 10:40 AM, Nick Coghlan wrote: Well, that and the beta deadline (we have to draw the line somewhere, or we'll be stuck in an eternal spiral of "just one more feature") Guido wanted to get the beta out when we did exactly so we could draw this line in the sand. I'd much rather people be spending time getting what features we do have tested, stabilized, bug fixed, and turning the buildbots green across the board. Having been caught by the 2.5 beta deadline with the changes that eventually became PEP 361 (and I think were significantly improved by the additional attention that was available due to the delay) I understand completely. (And to everyone with features that get bumped to 2.7/3.1 because of this... while a number of you no doubt know this already, it really is astonishing how soon the next release seems to roll around, even with our fairly leisurely release schedules!) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
On 26/06/2008, Eric Smith <[EMAIL PROTECTED]> wrote: > I actually think it's a useful feature, just not in bin(). I'm sure it will > land somewhere, and I'm also sure I'll use it, at least from the interactive > prompt. Can you give an example of its use? Maybe there are such examples in the tracker discussion, but I'm not following the tracker, and I think it would add some weight to the discussion here if use cases were noted. At the moment, the impression I get is that most of the python-dev comments are negative, but (without looking to confirm) most of the tracker comments are positive. If so, getting everything in one place will make it easier to see a balanced discussion. Having said all this, I agree with the point that this should be deferred to 2.7/3.1 now we're in beta. So there's hardly a rush. 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] Py3k DeprecationWarning in stdlib
On Fri, 27 Jun 2008 01:14:36 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: Jean-Paul Calderone wrote: [snip] The real problem with testing many uses of the warning system is that it doesn't expose enough public APIs for this to be possible. You *have* to use APIs which are, apparently, private (such as warn_explicit). Hmm, I think the bigger problem is that there is no documented way to save the warnings filter and restore it to a previous state - the 'filters' attribute (which holds the actual list of filters) isn't documented and isn't included in __all__. This makes it hard to write an officially supported test that fiddles with the warning settings then puts them back the way they were. It sounds like you're agreeing that there aren't enough public APIs. Making warn_explicit public addresses this particular problem in one way - by letting applications hook into the warning system before filters are applied. Making the filter list public is another way, since it would let applications clear and then restore the filters. I don't particularly care about the details, I just want some public API for this. Making warn_explicit public seems better to me, since it was already there in previous versions of Python, and it lets you completely ignore both the filters list and the global registry, but if others would rather make the filters and global registry a part of the public API, that's fine by me as well. 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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
On Thu, Jun 26, 2008 at 8:21 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Barry Warsaw wrote: >> >> On Jun 26, 2008, at 10:40 AM, Nick Coghlan wrote: >> >>> Well, that and the beta deadline (we have to draw the line somewhere, or >>> we'll be stuck in an eternal spiral of "just one more feature") >> >> Guido wanted to get the beta out when we did exactly so we could draw this >> line in the sand. I'd much rather people be spending time getting what >> features we do have tested, stabilized, bug fixed, and turning the buildbots >> green across the board. > > Having been caught by the 2.5 beta deadline with the changes that eventually > became PEP 361 (and I think were significantly improved by the additional > attention that was available due to the delay) I understand completely. > > (And to everyone with features that get bumped to 2.7/3.1 because of this... > while a number of you no doubt know this already, it really is astonishing > how soon the next release seems to roll around, even with our fairly > leisurely release schedules!) I'd like to separate the concerns though. I personally don't want to see the feature in its current form added to 2.7/3.1 either. As others pointed out, it's a wart on the bin/oct/hex functions. So as far as the feature design goes, I offer some suggestions: a new module; or a new function in math; or a new method on float. Since Raymond is the champion for the feature let him choose the API from those alternatives. Regarding the addition to 2.6/3.0 post beta 1, I think a new module has the most chance of success, especially if it's written in Python in such a way as to need minimal changes between 2.6 and 3.0. -- --Guido van Rossum (home page: http://www.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] Undocumenting test.support in 3.x (was Py3k DeprecationWarning in stdlib)
Guido van Rossum wrote: But I think we should think about this more. I don't think anyone expects the code inside any particular test_foo.py to have a stable public interface. But quite a bit of the test support infrastructure is reused by third party test frameworks. I think we should acknowledge and support such reuse. I'm personally fine with that approach, but some of the new items in there for 2.6 could probably use a bit of cleaning up to improve the APIs and/or the way they work. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] Community buildbots and Python release quality metrics
Too verbose, Glyph. :-) It needs to be decided case-by-case. The beta is called beta because, well, it may break stuff and we may want to fix it. But there are also likely many frameworks that use undefined behavior. I'm not particularly impressed by statistics like "all tests are red" -- this may all be caused by a single issue. For example, I'd much rather read an explanation about *why* Django cannot even be imported than a blanket complaint that this is a disgrace. So why is it? --Guido On Thu, Jun 26, 2008 at 8:18 AM, <[EMAIL PROTECTED]> wrote: > Today on planetpython.org, Doug Hellman announced the June issue of Python > magazine. The cover story this month is about Pybots, "the fantastic > automation system that has been put in place to make sure new releases of > Python software are as robust and stable as possible". > > Last week, there was a "beta" release of Python which, according to the > community buildbots, cannot run any existing python software. Normally I'd > be complaining here about Twisted, but in fact Twisted is doing relatively > well right now; only 80 failing tests. Django apparently cannot even be > imported. > > The community buildbots have been in a broken state for months now[1]. I've > been restraining myself from whinging about this, but now that it's getting > close to release, it's time to get these into shape, or it's time to get rid > of them. > > There are a few separate issues here. One is, to what extent should Python > actually be compatible between releases? There's not much point in saying > "this release is compatible with python 2.5" if all python 2.5 programs need > to be modified in order to run on python 2.6. Of course, it's quite likely > that there are some 3rd-party Python programs that continue to work, but > python.org provides links to 2 projects that don't and none that do. > > Another way to phrase this question is, "whose responsibility is it to make > Python 2.5 programs run on Python 2.6"? Or, "what happens when the core > team finds out that a change they have made has broken some python software > 'in the wild'"? > > Here are a couple of ways to answer these questions: > > 1) It's the python core team's responsibility. There should be Python > buildbots for lots of different projects and they should all be green before > the code can be considered [one of: allowed in trunk, alpha, beta, RC]. > 2) It's the python core team's responsibility as long as the major projects > are using public APIs. The code should not be considered [alpha, beta, RC] > if there are any known breakages in public APIs. > 3) It's only the python core team's responsibility to notify projects of > incompatible changes of which they are aware, which may occur in public or > private APIs. Major projects with breakages will be given a grace period > before a [beta, RC, final] to release a forward-compatible version. > 4) The status quo: every new Python release can (and will, at least > speaking in terms of 2.6) break lots of popular software, with no warning > aside from the beta period. There are no guarantees. > > For obvious reasons, I'd prefer #1, but any of the above is better than #4. > I don't think #4 is an intentional choice, either; I think it's the result > of there being no clear consequence for community buildbots failing. Or, > for that matter, of core buildbots failing. Investigating the history is > tricky (I see a bunch of emails from Barry here, but I'm not sure which is > the final state) but I believe the beta went out with a bunch of buildbots > offline or failing. > > A related but independent issue is: should the community buildbots continue > to exist? An automated test is only as good as the consequences of its > failure. As it stands, the community buildbots seem to be nothing but an > embarrassment. I don't mean this to slam Grig, or the Python team - I mean, > literally, if there is no consequence of their failure then the only use I > can see for the data the buildbots currently provide (i.e. months and months > of failures) is to embarrass the Python core developers. python.org's > purpose should not be to provide negative press for Python ;), so if this > continues to be the case, they probably shouldn't be linked. This isn't > just an issue with changes to Python breaking stuff; the pybots' > configuration is apparently not well maintained, since the buildbots which > say "2.5" aren't passing either, and that's not a problem with the code, > it's just that the slaves are actually running against [EMAIL PROTECTED] > > Ultimately these tools only exist to ensure the quality of Python releases. > The really critical question here is, what does it mean to have a Python > release that is high-quality? There are some obvious things: it shouldn't > crash, it should conform to its own documentation. Personally I think "it > passes all of its own tests" and "it runs existing Python code" are > important metrics too, but the mos
Re: [Python-Dev] Undocumenting test.support in 3.x (was Py3k DeprecationWarning in stdlib)
On Thu, Jun 26, 2008 at 8:32 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: >> >> But I think we should think about this more. I don't think anyone >> expects the code inside any particular test_foo.py to have a stable >> public interface. But quite a bit of the test support infrastructure >> is reused by third party test frameworks. I think we should >> acknowledge and support such reuse. > > I'm personally fine with that approach, but some of the new items in there > for 2.6 could probably use a bit of cleaning up to improve the APIs and/or > the way they work. So get crackin'! -- --Guido van Rossum (home page: http://www.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] Community buildbots and Python release quality metrics
[EMAIL PROTECTED] wrote: Today on planetpython.org, Doug Hellman announced the June issue of Python magazine. The cover story this month is about Pybots, "the fantastic automation system that has been put in place to make sure new releases of Python software are as robust and stable as possible". Last week, there was a "beta" release of Python which, according to the community buildbots, cannot run any existing python software. Normally I'd be complaining here about Twisted, but in fact Twisted is doing relatively well right now; only 80 failing tests. Django apparently cannot even be imported. beta 1 has some trouble running *our* test suite - I'd be fairly surprised if the community buildbots were in significantly better shape. The community buildbots have been in a broken state for months now[1]. Continuously running community buildbots on the maintenance trees makes sense, since those trees should always be in a releasable state. For the trunk, they're really only interesting when the Python core buildbots are reporting all green, but some of the community buildbots are reporting red. One of the problems is what the term "beta" means to different groups - for us, this first beta was really about saying "zero new features from here on, focus on making what we have now work properly". The relatively late landing of a couple of major PEPs (371, 3108) also didn't do any favours for trunk stability. If the community buildbots aren't largely green by the time beta 2 comes out, that's when I'll agree we have a problem - they should definitely be green by the time first release candidate comes out. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
Guido van Rossum wrote: I personally don't want to see the feature in its current form added to 2.7/3.1 either. As others pointed out, it's a wart on the bin/oct/hex functions. So as far as the feature design goes, I offer some suggestions: a new module; or a new function in math; or a new method on float. Since Raymond is the champion for the feature let him choose the API from those alternatives. Regarding the addition to 2.6/3.0 post beta 1, I think a new module has the most chance of success, especially if it's written in Python in such a way as to need minimal changes between 2.6 and 3.0. One of the other reasons I'd like to postpone the feature is that I think with a clean design behind it it could be an elegant addition to those builtins rather than a wart. But helping Raymond to convince you or anyone else of that is well down my to-do list at the moment (which I think just got longer with the test_support discussion...) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] Py3k DeprecationWarning in stdlib
Jean-Paul Calderone wrote: I don't particularly care about the details, I just want some public API for this. Making warn_explicit public seems better to me, since it was already there in previous versions of Python, and it lets you completely ignore both the filters list and the global registry, but if others would rather make the filters and global registry a part of the public API, that's fine by me as well. Why do you say warn_explicit isn't public? It's in both the 2.5 and 2.6 API docs for the warnings module. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] Py3k DeprecationWarning in stdlib
On Fri, 27 Jun 2008 01:52:18 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: Jean-Paul Calderone wrote: I don't particularly care about the details, I just want some public API for this. Making warn_explicit public seems better to me, since it was already there in previous versions of Python, and it lets you completely ignore both the filters list and the global registry, but if others would rather make the filters and global registry a part of the public API, that's fine by me as well. Why do you say warn_explicit isn't public? It's in both the 2.5 and 2.6 API docs for the warnings module. Brett told me it was private (on this list several weeks or a month or so ago). It's also no longer called in 2.6 by the C implementation of the warning system. 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] Community buildbots and Python release quality metrics
On 03:33 pm, [EMAIL PROTECTED] wrote: Too verbose, Glyph. :-) Mea culpa. "Glyph" might be a less appropriate moniker than "Altogether too many glyphs". It needs to be decided case-by-case. If certain tests are to be ignored on a case-by-case basis, why not record that decision by disabling the test in the code? Otherwise, the decision inevitably gets boiled down to "it's okay to release the code with a bunch of tests failing, but I don't know which ones". As it was on Twisted when we used to make case-by-case decisions about failures, and as it is here now. The beta is called beta because, well, it may break stuff and we may want to fix it. That's also why the alpha is called an alpha. My informal understanding is that a beta should have no (or at least very few) known issues, with a medium level of confidence that no further ones will be found. An RC would have absolutely no known issues with a fairly high level of confidence that no further ones will be found. This would include the community buildbots basically working for the most part; I would not be surprised if there were a few tests that still had issues. But clearly the reality does not meet my informal expectations, so it would be nice to have something written down to check against. Still, I'm bringing this up now because it _is_ a beta, and I think it will be too late to talk about dealing with persistent test failures after the RCs start coming out. (Of course, I'm just being sneaky. I don't actually care if it's clearly documented, I just care that I stop having problems with incompatibility. But I believe having it clearly spelled out would actually prevent a lot of the problems that I've been having, since I don't think anyone would *intentionally* select a policy where every release breaks at least one major dependent project.) I'm not particularly impressed by statistics like "all tests are red" -- this may all be caused by a single issue. The issue, for me, is not specifically that tests are red. It's that there's no clear policy about what to do about that. Can a release go out with some of the tests being red? If so, what are the extenuating circumstances? Does this have to be fixed? If not, why not? Why are we talking about this now? Shouldn't the change which caused Django to become unimportable have been examined at the time, rather than months later? (In other words, if it *is* a single issue, great, it's easy to fix: revert that single issue.) If not, then shouldn't someone in Django-land have been notified so they could cope with the change? Sorry that there are so many questions here; if I had fewer, I'd use fewer words to ask them. For example, I'd much rather read an explanation about *why* Django cannot even be imported than a blanket complaint that this is a disgrace. So why is it? I don't know. JP is already addressing the issues affecting Twisted in another thread (incompatible changes in the private-but-necessary-to- get-any-testing-done API of the warnings module). But I really think that whoever made the change which broke it should be the one investigating it, not me. ___ 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] Community buildbots and Python release quality metrics
On 03:42 pm, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: beta 1 has some trouble running *our* test suite - I'd be fairly surprised if the community buildbots were in significantly better shape. That's another problem, yes :) The community buildbots have been in a broken state for months now[1]. If the community buildbots aren't largely green by the time beta 2 comes out, that's when I'll agree we have a problem - they should definitely be green by the time first release candidate comes out. I have mixed feelings about this: on the one hand, if this were a matter of public record, I would have known that this was too early to start complaining, and we could have saved everyone a lot of time reading these messages. That would be good; I would prefer to just let everyone work without bothering about process. On the other hand, it's much easier to deal with test failures as they arise than in one giant chunk of work at the end of the development process. I spoke to a few core developers at PyCon who thought that the buildbots should always be green and any change that broke them should be reverted. They may remain nameless unless they wish to raise their hands :-) but that's definitely how I feel about it. Continuously running community buildbots on the maintenance trees makes sense, since those trees should always be in a releasable state. For the trunk, they're really only interesting when the Python core buildbots are reporting all green, but some of the community buildbots are reporting red. (... which should be all the time ...) One of the problems is what the term "beta" means to different groups - for us, this first beta was really about saying "zero new features from here on, focus on making what we have now work properly". The relatively late landing of a couple of major PEPs (371, 3108) also didn't do any favours for trunk stability. A big part of why I wrote this message is that I wanted a clear understanding of the relationship between the definition of "alpha", "beta" and "RC" and the state of various buildbots. If that relationship exists already, just linking to it from http://python.org/download/releases/2.6/ would be good. By the way, that page still says these are "alpha" releases. ___ 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] Community buildbots and Python release quality metrics
On Thu, Jun 26, 2008 at 5:33 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > an explanation about *why* Django cannot even be imported than a > blanket complaint that this is a disgrace. So why is it? > File "/home/ralf/pediapress/appserver/django/db/models/options.py", line 198, in _many_to_many self._fill_m2m_cache() File "/home/ralf/pediapress/appserver/django/db/models/options.py", line 221, in _fill_m2m_cache cache[field] = None File "/home/ralf/pediapress/appserver/django/utils/datastructures.py", line 75, in __setitem__ super(SortedDict, self).__setitem__(key, value) TypeError: unhashable type: 'ManyToManyField' same for sqlalchemy: egg/sqlalchemy/schema.py", line 113, in __call__ return type.__call__(self, name, metadata, *args, **kwargs) File "/home/ralf/py26/lib/python2.6/site-packages/SQLAlchemy-0.5.0beta1-py2.6.egg/sqlalchemy/schema.py", line 207, in __init__ self.primary_key = PrimaryKeyConstraint() File "/home/ralf/py26/lib/python2.6/site-packages/SQLAlchemy-0.5.0beta1-py2.6.egg/sqlalchemy/schema.py", line 294, in _set_primary_key self.constraints.add(pk) TypeError: unhashable type: 'PrimaryKeyConstraint' and already discussed: http://mail.python.org/pipermail/python-dev/2008-April/078421.html - Ralf ___ 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] Community buildbots and Python release quality metrics
Ralf Schmitt wrote: TypeError: unhashable type: 'ManyToManyField' TypeError: unhashable type: 'PrimaryKeyConstraint' and already discussed: http://mail.python.org/pipermail/python-dev/2008-April/078421.html Following the discussion to it's conclusions leads one to a tracker issue [1] that was supposed to be a blocker for the beta but (I assume) was forgotten about. Clearly this should be promoted to being a blocker again and some decision made. [1] http://bugs.python.org/issue2235 -- 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] Community buildbots and Python release quality metrics
On 04:42 pm, [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 5:33 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: an explanation about *why* Django cannot even be imported than a blanket complaint that this is a disgrace. So why is it? and already discussed: http://mail.python.org/pipermail/python-dev/2008-April/078421.html Following that trail of breadcrumbs, I ended up here: http://bugs.python.org/issue2235 with a message from some guy named "Barry Warsaw" (anyone know him?) that says: """ Guido, can you comment on Amaury's latest patch? I'm going to bump this back to critical so as not to hold up 2.6 alpha, but it should be marked as a release blocker for the first beta. """ I don't know if this "Barry" guy has the appropriate permissions on the bugtracker to increase priorities, so I've taken the liberty of upgrading it as a release blocker for the _second_ beta ... ;-). So, at least there's been one productive consequence of this discussion. ___ 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] Community buildbots and Python release quality metrics
On Thu, Jun 26, 2008 at 9:21 AM, <[EMAIL PROTECTED]> wrote: > On 03:33 pm, [EMAIL PROTECTED] wrote: >> It needs to be decided case-by-case. > > If certain tests are to be ignored on a case-by-case basis, why not record > that decision by disabling the test in the code? Otherwise, the decision > inevitably gets boiled down to "it's okay to release the code with a bunch > of tests failing, but I don't know which ones". As it was on Twisted when > we used to make case-by-case decisions about failures, and as it is here > now. No, I just meant that we need to figure out for each 3rd party test that fails whether the failure is our fault (too incompatibile) or theirs (relied on undefined behavior) and what the best fix is (change our code or theirs -- note that even if it's there fault there are cases where the best fix is to change our code. >> The beta is called beta because, well, it may break stuff and we may want >> to fix it. > > That's also why the alpha is called an alpha. My informal understanding is > that a beta should have no (or at least very few) known issues, with a > medium level of confidence that no further ones will be found. An RC would > have absolutely no known issues with a fairly high level of confidence that > no further ones will be found. This would include the community buildbots > basically working for the most part; I would not be surprised if there were > a few tests that still had issues. I guess we differ in interpretation. I see alphas as early outreach to the community. I see betas as a line in the sand where we stop adding/changing functionality -- but certainly not the moment where we expect everything to be perfect. During the beta period we fix bugs only -- those could be problems with new features, but those could also be problems where we accidentally introduced a backwards incompatibility. I'm sorry if your interpretation of the terminology is different, but this is mine and this is what we've always used, and it's not likely to change. (At least not for the 2.6/3.0 release.) > But clearly the reality does not meet my informal expectations, so it would > be nice to have something written down to check against. Still, I'm > bringing this up now because it _is_ a beta, and I think it will be too late > to talk about dealing with persistent test failures after the RCs start > coming out. Absolutely correct. The RCs are hoped to be as good as the final release. *Now* is the time to bring up issue. But please bring up specific issues -- I don't want to have an extended discussion about process or quality or expectations. I just want the code to be fixed. > (Of course, I'm just being sneaky. I don't actually care if it's clearly > documented, I just care that I stop having problems with incompatibility. > But I believe having it clearly spelled out would actually prevent a lot of > the problems that I've been having, since I don't think anyone would > *intentionally* select a policy where every release breaks at least one > major dependent project.) And here we seem to be parting our ways. We have a large amount of process already. I don't want more. >> I'm not particularly impressed by statistics like "all tests are red" -- >> this >> may all be caused by a single issue. > > The issue, for me, is not specifically that tests are red. It's that > there's no clear policy about what to do about that. Can a release go out > with some of the tests being red? If so, what are the extenuating > circumstances? Does this have to be fixed? If not, why not? Why are we > talking about this now? Shouldn't the change which caused Django to become > unimportable have been examined at the time, rather than months later? (In > other words, if it *is* a single issue, great, it's easy to fix: revert that > single issue.) If not, then shouldn't someone in Django-land have been > notified so they could cope with the change? > > Sorry that there are so many questions here; if I had fewer, I'd use fewer > words to ask them. If you're talking about community buildbots (which I presume are testing 3rd party packages against the core release) being red, that's out of scope for the core developers. We have enough trouble keeping our own (core) buildbots green, as you may have noticed. Some of the core buildbots are red because, well, frankly, they run on a cranky old version of an OS that few people care about. And then sometimes we leave them red, or turn them off. I see the core buildbots as a tool for developers to have their changes tested on a wide variety of platforms. They are an internal tool that gives us guidance about whether we're ready. I hope the community buildbots can be used the same way: a red bot means someone needs to look into an issue. The issue could be with the core or with the 3rd party package being tested. I don't think a policy like "no community buildbots should be red" makes any sense. >> For example, I'd much rather read an explanation about
Re: [Python-Dev] Community buildbots and Python release quality metrics
And just to make my position perfectly clear, I've unassigned it, since I don't foresee to be able to give this issue the quality time it clearly needs. Mind you, I agree it's a release blocker. But I don't have time to personally investigate it. Sorry. On Thu, Jun 26, 2008 at 9:54 AM, <[EMAIL PROTECTED]> wrote: > On 04:42 pm, [EMAIL PROTECTED] wrote: >> >> On Thu, Jun 26, 2008 at 5:33 PM, Guido van Rossum <[EMAIL PROTECTED]> >> wrote: >>> >>> an explanation about *why* Django cannot even be imported than a >>> blanket complaint that this is a disgrace. So why is it? > >> and already discussed: >> http://mail.python.org/pipermail/python-dev/2008-April/078421.html > > Following that trail of breadcrumbs, I ended up here: > > http://bugs.python.org/issue2235 > > with a message from some guy named "Barry Warsaw" (anyone know him?) that > says: > > """ > Guido, can you comment on Amaury's latest patch? I'm going to bump this > back to critical so as not to hold up 2.6 alpha, but it should be marked > as a release blocker for the first beta. > """ > > I don't know if this "Barry" guy has the appropriate permissions on the > bugtracker to increase priorities, so I've taken the liberty of upgrading it > as a release blocker for the _second_ beta ... ;-). So, at least there's > been one productive consequence of this discussion. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.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] Community buildbots and Python release quality metrics
> That's also why the alpha is called an alpha. My informal understanding > is that a beta should have no (or at least very few) known issues No, that's not the purpose. Instead, it is a promise that no further features will be added, i.e. that the code is stable from a feature point of view. It certainly will contain bugs. The final release will certainly contain bugs, just look at the long list of open bug reports. > The issue, for me, is not specifically that tests are red. It's that > there's no clear policy about what to do about that. Can a release go > out with some of the tests being red? If so, what are the extenuating > circumstances? The final release, no. The beta release: sure (in particular if it's the first beta release). Also make a difference between the Python buildbots, and the community buildbots. I think few if any core committers ever look at the status of the community buildbots - the community has to bring breakage to our attention (as you just did). > Does this have to be fixed? If not, why not? Here, I'm confused what specifically you talk about. That Django doesn't import? It is certainly not part of the release procedure to verify that Django can still be imported. > Why are > we talking about this now? Shouldn't the change which caused Django to > become unimportable have been examined at the time, rather than months > later? Somebody should have pointed it out when it happened. Unfortunately, nobody did, so apparently, the community doesn't really care. > I don't know. JP is already addressing the issues affecting Twisted in > another thread (incompatible changes in the private-but-necessary-to- > get-any-testing-done API of the warnings module). But I really think > that whoever made the change which broke it should be the one > investigating it, not me. How could they have known that they broke it? 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] Community buildbots and Python release quality metrics
> A big part of why I wrote this message is that I wanted a clear > understanding of the relationship between the definition of "alpha", > "beta" and "RC" and the state of various buildbots. If that > relationship exists already, just linking to it from > http://python.org/download/releases/2.6/ would be good. By the way, > that page still says these are "alpha" releases. I think its significantly simpler to answer specific questions on the mailing list, to educate the specific set of people who have this question, than to put an official answer on the web page. So I'm skeptical that anybody will change the web page - just continue asking questions as you encounter them. 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] Community buildbots and Python release quality metrics
On Thu, Jun 26, 2008 at 6:54 PM, <[EMAIL PROTECTED]> wrote: > On 04:42 pm, [EMAIL PROTECTED] wrote: >> >> On Thu, Jun 26, 2008 at 5:33 PM, Guido van Rossum <[EMAIL PROTECTED]> >> wrote: >>> >>> an explanation about *why* Django cannot even be imported than a >>> blanket complaint that this is a disgrace. So why is it? > >> and already discussed: >> http://mail.python.org/pipermail/python-dev/2008-April/078421.html > > Following that trail of breadcrumbs, I ended up here: > > http://bugs.python.org/issue2235 > > with a message from some guy named "Barry Warsaw" (anyone know him?) that > says: > > """ > Guido, can you comment on Amaury's latest patch? I'm going to bump this > back to critical so as not to hold up 2.6 alpha, but it should be marked > as a release blocker for the first beta. > """ > > I don't know if this "Barry" guy has the appropriate permissions on the > bugtracker to increase priorities, so I've taken the liberty of upgrading it > as a release blocker for the _second_ beta ... ;-). So, at least there's > been one productive consequence of this discussion. this patch even make things worse for me. now py.test also dies. ___ 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] Community buildbots and Python release quality metrics
On Thu, Jun 26, 2008 at 10:40 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote: > this patch even make things worse for me. now py.test also dies. Please add details to the tracker. -- --Guido van Rossum (home page: http://www.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] Community buildbots and Python release quality metrics
On Thu, Jun 26, 2008 at 7:55 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Thu, Jun 26, 2008 at 10:40 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote: >> this patch even make things worse for me. now py.test also dies. > > Please add details to the tracker. > Well, I think most probably the patch is correct and it just catches another class which defines __eq__ but does not define __hash__. So nothing to add there. The question is if this behaviour should be kept or not. I guess there's no bug tracking that... ___ 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-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
From: "Guido van Rossum" <[EMAIL PROTECTED]> So as far as the feature design goes, I offer some suggestions: a new module; or a new function in math; or a new method on float. Since Raymond is the champion for the feature let him choose the API from those alternatives. I choose bin/hex/oct methods on floatobjects. Will work-up a patch. 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] Community buildbots and Python release quality metrics
On Thu, Jun 26, 2008 at 11:07 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote: > On Thu, Jun 26, 2008 at 7:55 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> On Thu, Jun 26, 2008 at 10:40 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote: >>> this patch even make things worse for me. now py.test also dies. >> >> Please add details to the tracker. > Well, I think most probably the patch is correct and it just catches > another class which defines __eq__ but does not define __hash__. So > nothing to add there. So you're saying py.test needs to be fixed? Fine with me, but then I don't understand why you bothered bringing it up here instead of fixing it (or reporting to the py.test maintainers, I don't know if you're one or not). > The question is if this behaviour should be kept or not. I guess > there's no bug tracking that... The best place is that very same issue. If this feature is really too annoying something needs to be done. Detailed reports about real code that gets broken without a good cause help making that case. -- --Guido van Rossum (home page: http://www.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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
On Thu, Jun 26, 2008 at 11:07 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > From: "Guido van Rossum" <[EMAIL PROTECTED]> >> >> So as far as the feature design goes, I offer some suggestions: a new >> module; or a new function in math; or a new method on float. Since >> Raymond is the champion for the feature let him choose the API from >> those alternatives. > > I choose bin/hex/oct methods on floatobjects. > Will work-up a patch. Let's step back and discuss the API some more. - Do we need all three? - If so, why not .tobase(N)? (Even if N is restricted to 2, 8 and 16.) - What should the output format be? I know you originally favored 0b10101.010101 etc. Now that it's not overloaded on the bin/oct/hex builtins, the constraint that it needs to be an eval() able expression may be dropped (unless you see a use case for that too). -- --Guido van Rossum (home page: http://www.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] Disable tests in unittest (issue3202)
On Thu, Jun 26, 2008 at 10:51:49AM +1000, Jonathan Lange wrote:
> On Thu, Jun 26, 2008 at 7:13 AM, Justin Mazzola Paluska <[EMAIL PROTECTED]>
> wrote:
> I think it's really worth looking at the approach that bzrlib's tests
> take here (see bzrlib.tests.ExtendedTestResult and the
> out-of-date-but-helpful http://bazaar-vcs.org/BzrExtendTestSuite)
>
> Instead of disabling the tests, their practice is to run the tests but
> have them raise KnownFailure. When they write a test that they know
> will fail, they have it raise this exception. The extended TestResult
> object catches this exception in addFailure and reports it
> appropriately.[1]
I wasn’t aware of bzrlib’s extentions to unittest — many of them,
including KnownFailure, TestSkipped,
bzrlib.test.ExtendedTestResult.expectFailure, and the sundry list of
bzrlib.test.TestCase.assert* look useful enough to belong in the
standard library.
> I can see that disabling still has some value, but I'd rather have
> KnownFailure first.
I think disabling and the bzr extensions have different use cases.
KnownFailure lets someone with an intimate knowledge of the the
failing test case write down that they expect the test to fail. The
disabled decorator lets someone less familiar with the test cases to
easily disable tests that are getting in their way, without needing to
understand the body of the test function (or worse, mis-understanding
it and breaking it in a hard-to-understand way).
I agree that in the ideal world, we’d like to have both. In fact, if
we had the bzr extensions, it’d be easy to write the disabled
decorator in terms of their KnownFailure:
def disabled(func):
@wraps(func):
def wrapper(*args, **kwargs):
raise KnownFailure("%s disabled" % func.__name__)
return wrapper
However, unless Python’s unittest is going to incorporate the useful
features of bzrlib’s TestCase object[*], it probably makes sense to
implement the disabled feature separately.
—Justin
[*] Perhaps in the long term, this is the right thing to do as
unittest seems to have fallen behind in useful feature count as its
“conceptual” parent JUnit.
___
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] Py3k DeprecationWarning in stdlib
Guido van Rossum schrieb: Ok, then we're back to there being no supported way to write tests that need to intercept warnings. Twisted has already suffered from this (JP reports that Twisted's assertWarns is broken in 2.6), and I doubt it's alone. So I guess I am filing a bug after all... :) Yeah - Brett's correct that everything under "test.test_support" should really be formally undocumented. It's mostly a place for code that reflects "things we do a lot in our unit tests and are tired of repeating" rather than "this is a good API that we want to support forever and encourage other people to use". I still have a big problem with this attitude. If it's valuable enough to share between our tests, it should be properly written for reuse and documented. A collection of hacks remains a collection of hacks. We can do better. Since this is part of Benjamin's project, we will make sure that the test_support that emerges from it will be properly documented, stable and usable. Georg ___ 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] Community buildbots and Python release quality metrics
I do tend to ramble on, so here's an executive summary of my response: I want python developers to pay attention to the community buildbots and to treat breakages of existing projects as a serious issue. However, I don't think that maintaining those projects is the core team's job, so all I'm asking for is for core developers to: * treat breakages of 3rd party packages as a potentially serious issue, * if possible (i.e. if they find out about the breakage soon enough, which should be the case in any pybots failure) revert the change that caused the problem until the problem can be fixed, and * notify 3rd party maintainers when it's decided that the breakage will not be fixed. This only applies to breakages that the core developers find out about, which for all practical purposes means the ones on the community builders page. Those of you looking for point-by-point responses and some repetition of the above points, enjoy :). On 05:03 pm, [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 9:21 AM, <[EMAIL PROTECTED]> wrote: On 03:33 pm, [EMAIL PROTECTED] wrote: It needs to be decided case-by-case. (misunderstanding) No, I just meant that we need to figure out for each 3rd party test that fails whether the failure is our fault (too incompatibile) or theirs (relied on undefined behavior) and what the best fix is (change our code or theirs -- note that even if it's there fault there are cases where the best fix is to change our code. This is basically fine, as far as I'm concerned. I would like to suggest, however, that these issues be dealt with as soon as possible, rather than waiting for the release process to begin. A lot of decisions are made on this mailing list about the supposed properties of "average" python code, without any actual survey of said code. Sometimes the results of that survey can be really surprising. The end goal of any particular compatibility policy, of a distinction between "public" and "private" APIs, and so on, is to keep code working. I'm sorry if your interpretation of the terminology is different, but this is mine and this is what we've always used, and it's not likely to change. (At least not for the 2.6/3.0 release.) I have no problem with your definitions of these terms. I think that they should probably be in PEP 101 though. Would you accept a patch that added an edited / expanded version of this paragraph? Still, I'm bringing this up now because it _is_ a beta, Absolutely correct. The RCs are hoped to be as good as the final release. *Now* is the time to bring up issue. Well, that's good, at least :) But please bring up specific issues -- I don't want to have an extended discussion about process or quality or expectations. I just want the code to be fixed. Well, one specific issue has been bumped in priority as a result of this thread, and others are under discussion. The code is getting fixed. (I just care that I stop having problems with incompatibility.) And here we seem to be parting our ways. We have a large amount of process already. I don't want more. Looking at it from my perspective, I'm proposing a reduction in process. Under the current process, if a buildbot goes red, the developer makes a judgment call, the release manager makes a judgment call, there's discussion on a ticket, a ticket gets filed, it gets promoted, it gets demoted, the RM forgets to re-promote it... My suggestion is that the process be, simply: if a buildbot (community or otherwise) goes red, the change that broke it gets reverted. No questions asked! It's still there in the revision history, ready to be re-applied once the issues get worked out. Discussion can then take place and case-by-case judgments can be applied. If you're talking about community buildbots (which I presume are testing 3rd party packages against the core release) being red, that's out of scope for the core developers. I don't necessarily think that keeping the community buildbots red is the core developers' responsibility, but I don't think it should be entirely out of scope, either. The python test suite is, frankly, poor - and I hope I'm not surprising you by saying that. It's full of race conditions, tends to fail intermittently, and is frequently ignored. Not only that, but it is quite often changed, so tests for issues that affect real code are quite often removed. So, the community buildbots are not just making sure that 3rd-party code still works, they are an expanded, independently developed test suite to make sure that *python itself* still works. Sometimes they will not fill that role particularly well, but they are worth paying attention to. If python had a good, exhaustive regression test suite that was immutable between major versions, I'd probably feel differently. But that's not the world we live in. Right now, apparently, the *default* policy is that if the community buildbots go red, later, before a release, s
Re: [Python-Dev] Community buildbots and Python release quality metrics
On 05:14 pm, [EMAIL PROTECTED] wrote: I don't know. JP is already addressing the issues affecting Twisted in another thread (incompatible changes in the private-but-necessary-to- get-any-testing-done API of the warnings module). But I really think that whoever made the change which broke it should be the one investigating it, not me. How could they have known that they broke it? Because the relevant community buildbot turned red with that revision of trunk. Keep in mind I'm not talking about every piece of Python code in the universe; just the ones selected for the community buildbots. It would be nice if there were a dozen or so projects on there, but paying attention to the two builders that do actually run right now would be a good start. ___ 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] Community buildbots and Python release quality metrics
[EMAIL PROTECTED] schrieb: Another way to phrase this question is, "whose responsibility is it to make Python 2.5 programs run on Python 2.6"? Or, "what happens when the core team finds out that a change they have made has broken some python software 'in the wild'"? Here are a couple of ways to answer these questions: 1) It's the python core team's responsibility. There should be Python buildbots for lots of different projects and they should all be green before the code can be considered [one of: allowed in trunk, alpha, beta, RC]. 2) It's the python core team's responsibility as long as the major projects are using public APIs. The code should not be considered [alpha, beta, RC] if there are any known breakages in public APIs. > 3) It's only the python core team's responsibility to notify projects of incompatible changes of which they are aware, which may occur in public or private APIs. Major projects with breakages will be given a grace period before a [beta, RC, final] to release a forward-compatible version. 4) The status quo: every new Python release can (and will, at least speaking in terms of 2.6) break lots of popular software, with no warning aside from the beta period. There are no guarantees. Python's backwards compatibility has never extended to non-public APIs. That rules out 1). 2) would be nice, but to be honest, 2) and 3) are unrealistic given the number of Python core developers and the tasks already at hand. 4) is not acceptable either. However, you seem to be overlooking that there's a 3.5) in there: it's the Python core team's responsibility as long as the major projects are using public APIs; but to reduce the workload every project should watch its own buildbots and notify the core team using the issue tracker in order to get the issue resolved. At no time will a policy "the community buildbots must be green" be useful: the tests that run on these buildbots are not under our control, so if the tests test things we deem non-public we can't do anything about it. (And we may have a hard time convincing project authors to change the tests if we promised to make them run anyway.) Georg ___ 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] Community buildbots and Python release quality metrics
[EMAIL PROTECTED] schrieb: On 03:42 pm, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: beta 1 has some trouble running *our* test suite - I'd be fairly surprised if the community buildbots were in significantly better shape. That's another problem, yes :) The community buildbots have been in a broken state for months now[1]. If the community buildbots aren't largely green by the time beta 2 comes out, that's when I'll agree we have a problem - they should definitely be green by the time first release candidate comes out. I have mixed feelings about this: on the one hand, if this were a matter of public record, I would have known that this was too early to start complaining, and we could have saved everyone a lot of time reading these messages. That would be good; I would prefer to just let everyone work without bothering about process. The problem is that not enough people care about the community buildbots, and this isn't likely to improve since we have not enough manpower to do it. On the other hand, it's much easier to deal with test failures as they arise than in one giant chunk of work at the end of the development process. I spoke to a few core developers at PyCon who thought that the buildbots should always be green and any change that broke them should be reverted. They may remain nameless unless they wish to raise their hands :-) but that's definitely how I feel about it. I think no core developer will not tell you that the (core) buildbots should be green all the time. As for reverting changes that break, I'd support this only for changes that break *all* of them. For example, I only use one platform to develop on (and I guess it's the same for many others), having the buildbots go red on another platform means I can try to fix the issue. Georg ___ 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] Community buildbots and Python release quality metrics
To me (and I'm an outsider not a direct developer), it's Python developers responsibility to handle the Python problems and the Python build bots. The community build bots are the responsibility of their authors. If JP is handling the Twisted one then great. It's got a gatekeeper. If no one is handling the Django build bot that's not the Python Dev Team's problem but is a problem on the Django side and someone involved in that should be tasked with monitoring. Having said all that, I agree that the community bots ought to at least be looked at. If I check in a patch in and I notice that a community bot went from green to red then I probably should double check my code. The problem is that, as you said, the community bots haven't been well maintained... They've been red for awhile. So asking the developers to then go do the leg work to find the original error, fix it and then back check everything between then and now that might have ALSO caused a problem is alot of effort. It's not the Bank's responsibility to balance my check book. They give me the tools to do it and then I have to check. A similar principle applies here, I believe. ___ 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] Community buildbots and Python release quality metrics
On Thu, 26 Jun 2008 21:46:48 +0200, Georg Brandl <[EMAIL PROTECTED]> wrote: [snip] As for reverting changes that break, I'd support this only for changes that break *all* of them. For example, I only use one platform to develop on (and I guess it's the same for many others), having the buildbots go red on another platform means I can try to fix the issue. BuildBot has two ways to let you run your code on all builders before you commit it to trunk. You can force a build on a branch or you can try a build with a patch. I don't know if these options are enabled on Python's buildmaster. If they are, then if you want, you can use them to make sure your code works on all platforms before you put it into trunk, where it may cause problems for someone else. 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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
From: "Guido van Rossum" <[EMAIL PROTECTED]> Let's step back and discuss the API some more. - Do we need all three? I think so -- see the the reasons below. Of course, my first choice was not on your list. To me, the one obvious way to convert a number to a eval-able string in a different base is to use bin(), oct(), or hex(). But that appears to be off the table for reasons that I've read but don't make any sense to me. It seems simple enough, extendable enough, and clean enough for bin/oct/hex to use __index__ if present and __float__ if not. - If so, why not .tobase(N)? (Even if N is restricted to 2, 8 and 16.) I don't think it's user-friendly to have the float-to-bin API fail to parallel the int-to-bin API. IMO, it should be done the same way in both places. I don't find it attractive in appearance. Any use case I can imagine involves multiple calls using the same base and I would likely end-up using functools.partial or somesuch to factor-out the repeated use of the same variable. In particular, it's less usable with a series of numbers at the interactive prompt. That is one of the primary use cases since it allows you to see exactly what is happening with float arithmetic: .6 + .7 1.2998 bin(.6) '0b10011001100110011001100110011001100110011001100110011 * 2.0 ** -53' bin(.7) '0b1011001100110011001100110011001100110011001100110011 * 2.0 ** -52' bin(.6 + .7) '0b101001100110011001100110011001100110011001100110011 * 2.0 ** -50' bin(1.3) '0b10100110011001100110011001100110011001100110011001101 * 2.0 ** -52' Or checking whether a number is exactly representable: bin(3.375) '0b11011 * 2.0 ** -3' Both of those bits of analysis become awkward with the tobase() method: (.6).tobase(2) ... - What should the output format be? I know you originally favored 0b10101.010101 etc. Now that it's not overloaded on the bin/oct/hex builtins, the constraint that it needs to be an eval() able expression may be dropped (unless you see a use case for that too). The other guys convinced me that round tripping was important and that there is a good use case for being able to read/write precisely specified floats in a platform independent manner. Also, my original idea didn't scale well without exponential notation -- i.e. bin(125E-100) would have a heckofa lot of leading zeroes. Terry and Mark also pointed-out that the hex with exponential notation was the normal notation used in papers on floating point arithmetic. Lastly, once I changed over to the new way, it dramatically simplified the implementation. 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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
>> So as far as the feature design goes, I offer some suggestions: a new >> module; or a new function in math; or a new method on float. Since >> Raymond is the champion for the feature let him choose the API from >> those alternatives. > > I choose bin/hex/oct methods on floatobjects. > Will work-up a patch. I think the feature is misguided in the first place. Why do you want a hex representation of floating point numbers? Can't you use struct.pack for that? And, if bin/hex/oct are useful, why not base 6 (say)? 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] Community buildbots and Python release quality metrics
> I want python developers to pay attention to the community buildbots I don't think that goal is realistic. Instead, somebody who has actual interest in this matter should pay this attention, and then bring it up on python-dev when something breaks. 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] Community buildbots and Python release quality metrics
[EMAIL PROTECTED] wrote: to what extent should Python actually be compatible between releases? As I understand things from years of observation, the following are fair game to changed in ways possibly backward-incompatible for specific code: bugs, detailed float behavior (which may be system-specific anyway), error messages, private interfaces, non-enforcement of documented rules, and defined implementation-dependent behavior. But Guido has been somewhat conservative about this (least so for bug fixes, I think) and sometimes put off changes even when the fault lies with questionable usages. One fly in the ointment is that bugs (a discrepancy between doc and code) may be fixed either by changing the doc or the code, according to which embodies the design intention. So neither can be taken as gospel. ___ 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] Community buildbots and Python release quality metrics
Georg Brandl wrote: [EMAIL PROTECTED] schrieb: Another way to phrase this question is, "whose responsibility is it to make Python 2.5 programs run on Python 2.6"? Or, "what happens when the core team finds out that a change they have made has broken some python software 'in the wild'"? Here are a couple of ways to answer these questions: 1) It's the python core team's responsibility. There should be Python buildbots for lots of different projects and they should all be green before the code can be considered [one of: allowed in trunk, alpha, beta, RC]. 2) It's the python core team's responsibility as long as the major projects are using public APIs. The code should not be considered [alpha, beta, RC] if there are any known breakages in public APIs. > 3) It's only the python core team's responsibility to notify projects of incompatible changes of which they are aware, which may occur in public or private APIs. Major projects with breakages will be given a grace period before a [beta, RC, final] to release a forward-compatible version. 4) The status quo: every new Python release can (and will, at least speaking in terms of 2.6) break lots of popular software, with no warning aside from the beta period. There are no guarantees. Python's backwards compatibility has never extended to non-public APIs. That rules out 1). 2) would be nice, but to be honest, 2) and 3) are unrealistic given the number of Python core developers and the tasks already at hand. 4) is not acceptable either. However, you seem to be overlooking that there's a 3.5) in there: it's the Python core team's responsibility as long as the major projects are using public APIs; but to reduce the workload every project should watch its own buildbots and notify the core team using the issue tracker in order to get the issue resolved. At no time will a policy "the community buildbots must be green" be useful: the tests that run on these buildbots are not under our control, so if the tests test things we deem non-public we can't do anything about it. (And we may have a hard time convincing project authors to change the tests if we promised to make them run anyway.) If, however, the community buildbot goes red because of a regression or backwards incompatibility the developers should, when notified, at least undertake to verify that the breakage is intentional. Unfortunately having a buildbot is like installing a firewall. Some people assume that the very presence of the buildbot is a guard against version incompatibilities, whereas in truth there is always the messy business of communication required to ensure the information gets to where it is useful. The bottom line, of course, is that if project X can't be bothered to tell the core development team when changes break their build it's nobody's fault but their own. If the report it and the core developers ignore the reports, that's something that should be rectified. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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
Re: [Python-Dev] Community buildbots and Python release quality metrics
> BuildBot has two ways to let you run your code on all builders before you > commit it to trunk. You can force a build on a branch or you can try a > build with a patch. I don't know if these options are enabled on Python's > buildmaster. If they are, then if you want, you can use them to make sure > your code works on all platforms before you put it into trunk, where it may > cause problems for someone else. Even if that's possible, it adds a burden. As likely not all people agree that such a procedure would be a good thing, it's necessary that somebody establishes a policy. Guido has already indicated that he is not interested in further policies; Barry (the canonical other person to set policies) has indicated in the past that he would like such a policy, but deems it unrealistic at this point. He gives other procedural changes higher priority, so that realistically, such a policy might not be established within the next two years. 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] Community buildbots and Python release quality metrics
On 07:44 pm, [EMAIL PROTECTED] wrote:
At no time will a policy "the community buildbots must be green" be
useful: the tests that run on these buildbots are not under our
control,
so if the tests test things we deem non-public we can't do anything
about it. (And we may have a hard time convincing project authors to
change the tests if we promised to make them run anyway.)
That's not what I'm suggesting.
If there is a legitimate disagreement between Python developers and
developers of a project about whether an API should continue to be
supported, then clearly, the Python developers get to win. Welcome to
open source.
However, I believe that the core team is not paying attention to other
projects breaking. I'm not saying that you want to make breaking
changes, or that bug reports are not dealt with, but the problem is that
dealing with these problems after the fact makes it _much_ more painful.
When you get to the release, and you have 30 bug reports due to other
projects breaking, they get triaged, some get left in, and some features
of lots of different projects are left broken. And many projects do not
bother to test with the beta.
If developers were simply presented with the results of their changes
immediately ("you broke twisted, django doesn't import, zope segfaults
and mercurial destroys your repository") then perhaps they would weigh
the benefits of compatibility differently, and do the trivial, obvious
fix immediately, rather than waiting 6 months and having to figure out
what the heck change caused the bug. I accept the fact that python core
development is done differently than i.e. Java development, and some
backward compatibility may simply be broken.
Case in point: changes to the warnings module being discussed in a
separate thread break a significant number of Twisted's tests, because
they remove functionality which is not public but is required to test
code that uses the warnings module. Would Brett have taken this into
account if he knew about it immediately when revision 62303 was
committed? Maybe not, but now that the code is written and done,
there's significantly less motivation to go back and fix it. At the
time it might have only been a few minutes' work to continue supporting
the use-case which Twisted needs. Brett wouldn't even have necessarily
needed to do the work: it would have been easier to convince a Twisted
developer to do the work it to keep the community buildbot green rather
than to make it a bit less red. Now, though, it's much easier to say
"oh well, that's private, you lose". I don't ascribe this to malice -
it really *would* be much harder to fix it now, for us as well as for
him.
___
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] Undocumenting test.support in 3.x (was Py3k DeprecationWarning in stdlib)
On Thu, Jun 26, 2008 at 10:34 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Thu, Jun 26, 2008 at 8:32 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> I'm personally fine with that approach, but some of the new items in there >> for 2.6 could probably use a bit of cleaning up to improve the APIs and/or >> the way they work. > > So get crackin'! I'll add to my list. :) Anyway, if we are going to make test.support public for real why don't we take Nick's suggestion to rename the test package to _test, but move test.support to a toplevel position like testutils or such. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ 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-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
On Thu, Jun 26, 2008 at 8:55 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > I think the feature is misguided in the first place. Why do you want > a hex representation of floating point numbers? Answering for myself: because it gives an exact representation of a floating-point number in a fairly human-readable format. > Can't you use struct.pack for that? struct.pack would only show the bit layout, leaving the user to manually extract the sign bit, exponent, and fraction, and then make sense of the whole thing. The proposed feature works at a higher level of abstraction, directly describing the *value* of the float rather than its bit layout. In particular, this means it'll make sense across platforms, regardless of variations in bit layout. And, if bin/hex/oct are useful, why not base > 6 (say)? > I'd say that bin and hex are special: bin is natural because floats are usually thought of, and stored as, binary numbers. hex is special because it gives a compact way of representing a float, and because there's already a history of using hex floats in numerical analysis literature and in programming languages (C99, Java, ...) I have to admit that I can't see much use for octal floats. 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] Py3k DeprecationWarning in stdlib
On Thu, Jun 26, 2008 at 12:33 PM, Georg Brandl <[EMAIL PROTECTED]> wrote: > Guido van Rossum schrieb: > Ok, then we're back to there being no supported way to write tests that need to intercept warnings. Twisted has already suffered from this (JP reports that Twisted's assertWarns is broken in 2.6), and I doubt it's alone. So I guess I am filing a bug after all... :) >>> >>> Yeah - Brett's correct that everything under "test.test_support" should >>> really be formally undocumented. It's mostly a place for code that >>> reflects >>> "things we do a lot in our unit tests and are tired of repeating" rather >>> than "this is a good API that we want to support forever and encourage >>> other >>> people to use". >> >> I still have a big problem with this attitude. If it's valuable enough >> to share between our tests, it should be properly written for reuse >> and documented. A collection of hacks remains a collection of hacks. >> We can do better. > > Since this is part of Benjamin's project, we will make sure that the > test_support that emerges from it will be properly documented, stable > and usable. I'm assuming however that Benjamin's project will land in 2.7 or 3.1, right? If he's going to be refactoring tests all summer there's no way that can be merged into the trunk and the py3k branch right before the final release. -- --Guido van Rossum (home page: http://www.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] Community buildbots and Python release quality metrics
> I don't ascribe this to malice - > it really *would* be much harder to fix it now, for us as well as for him. I think I disagree. It's easier to fix it now than it was to fix it back then. Fixing it back then would have meant to constantly observe the buildbots, and keep them running, so it would be a huge effort to maintain the infrastructure just to find a the few changes that unintentially broke something. Looking at them now is a lot of effort, also. But this effort is feasible, once the root cause is identified, the patch causing it might just get backed out. Maintaining the community buildbots has proven infeasible. It's unfortunate that many package authors don't understand that not all breakage is deliberate, and that their only chance to get undesired breakage reverted is to report bugs NOW. 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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
On Thu, Jun 26, 2008 at 1:17 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote: > I'd say that bin and hex are special: bin is natural because > floats are usually thought of, and stored as, binary numbers. > hex is special because it gives a compact way of representing > a float, and because there's already a history of using hex > floats in numerical analysis literature and in programming > languages (C99, Java, ...) Can you show us what APIs and output formats C99 and Java support? Maybe we can borrow something from there rather than reinventing the wheel? -- --Guido van Rossum (home page: http://www.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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
>
> I think the feature is misguided in the first place. Why do you want
> a hex representation of floating point numbers?
>
>
> Answering for myself: because it gives an exact representation of a
> floating-point number in a fairly human-readable format.
Ok. But
py> binascii.hexlify(struct.pack("d", 3.14))
'1f85eb51b81e0940'
does that already, no? You won't know the precise value, but you won't
know that with hex support, either.
> struct.pack would only show the bit layout, leaving the user to
> manually extract the sign bit, exponent, and fraction, and then make
> sense of the whole thing.
I'd question that the user is able to make sense of a number when
mantissa and exponent is represented in hex.
> I'd say that bin and hex are special: bin is natural because
> floats are usually thought of, and stored as, binary numbers.
> hex is special because it gives a compact way of representing
> a float, and because there's already a history of using hex
> floats in numerical analysis literature and in programming
> languages (C99, Java, ...)
Then I'd argue that the feature should be symmetric: If there is
support for printing floating point numbers as hex, there should
also be support for hex floating point literals.
Also, to follow C's tradition, it would be better if that was
*not* integrated into the hex function (or a hex method), but
if there was support for %a in string formatting.
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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
[Mark Dickinson] I have to admit that I can't see much use for octal floats. Neither do I. They look weird to me. 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] Community buildbots and Python release quality metrics
[EMAIL PROTECTED] schrieb:
On 07:44 pm, [EMAIL PROTECTED] wrote:
At no time will a policy "the community buildbots must be green" be
useful: the tests that run on these buildbots are not under our
control,
so if the tests test things we deem non-public we can't do anything
about it. (And we may have a hard time convincing project authors to
change the tests if we promised to make them run anyway.)
That's not what I'm suggesting.
Sure, but I wanted to say that nevertheless :)
If there is a legitimate disagreement between Python developers and
developers of a project about whether an API should continue to be
supported, then clearly, the Python developers get to win. Welcome to
open source.
However, I believe that the core team is not paying attention to other
projects breaking.
Quite true. It is their duty to bring the breakage to our attention, if
they want to see results.
I'm not saying that you want to make breaking
changes, or that bug reports are not dealt with, but the problem is that
dealing with these problems after the fact makes it _much_ more painful.
When you get to the release, and you have 30 bug reports due to other
projects breaking, they get triaged, some get left in, and some features
of lots of different projects are left broken. And many projects do not
bother to test with the beta.
I thought we're talking about the projects that *do* use the buildbots?
If developers were simply presented with the results of their changes
immediately ("you broke twisted, django doesn't import, zope segfaults
and mercurial destroys your repository") then perhaps they would weigh
the benefits of compatibility differently, and do the trivial, obvious
fix immediately, rather than waiting 6 months and having to figure out
what the heck change caused the bug.
This sounds very nice in theory, but it must be implemented in a way that
does not add a burden to the developer, as Martin said.
> Case in point: changes to the warnings module being discussed in a
> separate thread break a significant number of Twisted's tests, because
> they remove functionality which is not public but is required to test
> code that uses the warnings module. Would Brett have taken this into
> account if he knew about it immediately when revision 62303 was
> committed? Maybe not, but now that the code is written and done,
> there's significantly less motivation to go back and fix it. At the
> time it might have only been a few minutes' work to continue supporting
> the use-case which Twisted needs. Brett wouldn't even have necessarily
> needed to do the work: it would have been easier to convince a Twisted
> developer to do the work it to keep the community buildbot green rather
> than to make it a bit less red. Now, though, it's much easier to say
> "oh well, that's private, you lose". I don't ascribe this to malice -
> it really *would* be much harder to fix it now, for us as well as for
> him.
I must say that I'm increasingly surprised by this discussion since it seems
that not only the Python core devs neglect the community buildbots.
Shouldn't the project authors have at least the same interest that their
code runs on the next major Python version? And while they don't necessarily
have more time to watch the buildbots than we have, the amount of what they
need to keep an eye on.
Georg
___
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] Py3k DeprecationWarning in stdlib
On Thu, Jun 26, 2008 at 3:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Thu, Jun 26, 2008 at 12:33 PM, Georg Brandl <[EMAIL PROTECTED]> wrote: >> >> Since this is part of Benjamin's project, we will make sure that the >> test_support that emerges from it will be properly documented, stable >> and usable. > > I'm assuming however that Benjamin's project will land in 2.7 or 3.1, > right? If he's going to be refactoring tests all summer there's no way > that can be merged into the trunk and the py3k branch right before the > final release. Good timing! Georg and I were just talking about this. You're correct; I've never imagined having it in before 2.6 or 3.0 final. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ 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] Community buildbots and Python release quality metrics
Terry Reedy schrieb: [EMAIL PROTECTED] wrote: to what extent should Python actually be compatible between releases? As I understand things from years of observation, the following are fair game to changed in ways possibly backward-incompatible for specific code: bugs, detailed float behavior (which may be system-specific anyway), error messages, private interfaces, non-enforcement of documented rules, and defined implementation-dependent behavior. But Guido has been somewhat conservative about this (least so for bug fixes, I think) and sometimes put off changes even when the fault lies with questionable usages. Which is the source of many unresolved open issues in the tracker -- everyone agrees that "it" is a bug and should be fixed, perhaps there's even a patch, but people may be using it this way, so nothing is done forever. (And these bugs usually are the kind of things we don't want to change in 3.0 either since they are subtle things.) However, I don't have a solution here, so I won't complain about it anymore. Georg ___ 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-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
On Thu, Jun 26, 2008 at 12:52 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> From: "Guido van Rossum" <[EMAIL PROTECTED]>
>>
>> Let's step back and discuss the API some more.
>>
>> - Do we need all three?
>
> I think so -- see the the reasons below.
Sounds like Mark Dickinson only cares about bin and hex.
> Of course, my first choice was not
> on your list. To me, the one obvious way to convert a number to a eval-able
> string in a different base is to use bin(), oct(), or hex(). But that
> appears to be off the table for reasons that I've read but don't make any
> sense to me.
> It seems simple enough, extendable enough, and clean enough
> for bin/oct/hex to use __index__ if present and __float__ if not.
That's not extendable to types that aren't int or float though. And it
would accept Decimal instances which seems a really odd thing to do.
>> - If so, why not .tobase(N)? (Even if N is restricted to 2, 8 and 16.)
>
> I don't think it's user-friendly to have the float-to-bin API
> fail to parallel the int-to-bin API. IMO, it should be done
> the same way in both places.
Consistency only goes so far. We have 0b, 0o and 0x notations for
integers, and the bin/oct/hex builtins are meant to invert those. We
don't have base-{2,8,16} literals for floats.
> I don't find it attractive in appearance. Any use case I can
> imagine involves multiple calls using the same base and I would likely
> end-up using functools.partial or somesuch
> to factor-out the repeated use of the same variable. In particular,
> it's less usable with a series of numbers at the interactive prompt. That is
> one of the primary use cases since it allows you to see
> exactly what is happening with float arithmetic:
>
.6 + .7
>
> 1.2998
bin(.6)
>
> '0b10011001100110011001100110011001100110011001100110011 * 2.0 ** -53'
bin(.7)
>
> '0b1011001100110011001100110011001100110011001100110011 * 2.0 ** -52'
bin(.6 + .7)
>
> '0b101001100110011001100110011001100110011001100110011 * 2.0 ** -50'
bin(1.3)
>
> '0b10100110011001100110011001100110011001100110011001101 * 2.0 ** -52'
>
> Or checking whether a number is exactly representable:
>
bin(3.375)
>
> '0b11011 * 2.0 ** -3'
>
> Both of those bits of analysis become awkward with the tobase() method:
>
(.6).tobase(2)
You don't need the parentheses around .6.
I think much fewer than 0.01% of Python users will ever need this.
It's a one-liner helper function if you prefer to say bin(x) instead
of x.bin().
>> - What should the output format be? I know you originally favored
>> 0b10101.010101 etc. Now that it's not overloaded on the bin/oct/hex
>> builtins, the constraint that it needs to be an eval() able expression
>> may be dropped (unless you see a use case for that too).
>
> The other guys convinced me that round tripping was important
> and that there is a good use case for being able to read/write
> precisely specified floats in a platform independent manner.
Can you summarize those reasons? Who are the users of that feature?
I'm still baffled why a feature whose only users are extreme experts
needs to have such a prominent treatment. Surely there are a lot more
Python users who call urlopen() or urlparse() all day long. Should
these be built-in functions then?
> Also, my original idea didn't scale well without exponential
> notation -- i.e. bin(125E-100) would have a heckofa lot
> of leading zeroes. Terry and Mark also pointed-out that
> the hex with exponential notation was the normal notation
> used in papers on floating point arithmetic. Lastly, once I
> changed over to the new way, it dramatically simplified the
> implementation.
I agree that you need to have a notation using an exponent. If it
weren't for the roundtripping, I'd probably have preferred something
which simply showed me the bits of the IEEE floating point number
broken out into mantissa and exponent -- that seems more educational
to me than normalizing things so that the last bit is nonzero.
--
--Guido van Rossum (home page: http://www.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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
On Thu, Jun 26, 2008 at 9:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Can you show us what APIs and output formats C99 and Java support? > Maybe we can borrow something from there rather than reinventing the > wheel? > Java's toHexString method is documented at: http://java.sun.com/javase/6/docs/api/java/lang/Double.html#toHexString(double) It's disadvantage from Python's point of view is that some features are IEEE 754 specific (e.g. treatment of subnormals, which don't exist for most other floating point types). C99s support for hex literals uses a similar format; the standard is less specific about the precise output format, but it's still of the form 0x1.p Incidentally, the funny 'p' for the exponent instead of 'e' is apparently there to avoid ambiguity in something like: 0x1e+3 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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
On Thu, Jun 26, 2008 at 9:30 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> > Answering for myself: because it gives an exact representation of a
> > floating-point number in a fairly human-readable format.
>
> Ok. But
>
> py> binascii.hexlify(struct.pack("d", 3.14))
> '1f85eb51b81e0940'
>
> does that already, no? You won't know the precise value, but you won't
> know that with hex support, either.
>
The output from hex_float(3.14) would be something like:
'0x1.91eb851eb851fp+1'
The exponent is still usually given in decimal; there's no need
for it to be hexadecimal for exactness.
I'd question that the user is able to make sense of a number when
> mantissa and exponent is represented in hex.
>
I think the above it still a bit easier to understand than
if one has to figure out where the sign/exponent and
exponent/fraction bit boundaries are, unbias the exponent,
and add the extra hidden '1' bit into the mantissa. That's
a lot of mental work.
> Then I'd argue that the feature should be symmetric: If there is
> support for printing floating point numbers as hex, there should
> also be support for hex floating point literals.
>
I agree with this. Or at least support for hex floating point
strings, if not literals.
>
> Also, to follow C's tradition, it would be better if that was
> *not* integrated into the hex function (or a hex method), but
> if there was support for %a in string formatting.
>
I'd be delighted with '%a' support.
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] Community buildbots and Python release quality metrics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 26, 2008, at 11:42 AM, Nick Coghlan wrote: If the community buildbots aren't largely green by the time beta 2 comes out, that's when I'll agree we have a problem - they should definitely be green by the time first release candidate comes out. Just FTR, I'll be looking at the Python buildbots and Roundup tracker to decide whether I think beta2 is in shape to be released or not. I definitely won't be tracking the non-core buildbots, so if something troublesome comes up there, you will have to submit a bug report to the Python tracker. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSGQEu3EjvBPtnXfVAQIp6QP/bOU+8vImlRkfKCXazYhi3yEXcNwCPpWI e3AoiOlgKbOhSPraNTyUBjC+OjuqHQttyMJz8TTpexSwhpG/erDIqUjRbkW0Yaas attvFZBYbJhF3qvHyLzmSp9U3oXY6VyWayL8ZdzIGcukEW7g8DgQNQyoGOE4kEeX i6+4RIRf+7A= =X1lh -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
Re: [Python-Dev] Community buildbots and Python release quality metrics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 26, 2008, at 12:54 PM, [EMAIL PROTECTED] wrote: On 04:42 pm, [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 5:33 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: an explanation about *why* Django cannot even be imported than a blanket complaint that this is a disgrace. So why is it? and already discussed: http://mail.python.org/pipermail/python-dev/2008-April/078421.html Following that trail of breadcrumbs, I ended up here: http://bugs.python.org/issue2235 with a message from some guy named "Barry Warsaw" (anyone know him?) that says: """ Guido, can you comment on Amaury's latest patch? I'm going to bump this back to critical so as not to hold up 2.6 alpha, but it should be marked as a release blocker for the first beta. """ I don't know if this "Barry" guy has the appropriate permissions on the bugtracker to increase priorities, so I've taken the liberty of upgrading it as a release blocker for the _second_ beta ... ;-). So, at least there's been one productive consequence of this discussion. Glyph, you did the right thing. I wish there was a way of marking a bug "not-release-blocker-for-now" and have it automatically update back to blocker at a certain time or after a certain event. I think it's valid for this issue to block beta2. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSGQF0XEjvBPtnXfVAQJwiQP/T9f33lNtAQ9/eooKEyVCDms7NXJE7mIf QPOQtXuTZdsfUl51OxkxewVj6ERZasHPwIB2c13HYuHRrMrmrE9EYStdbmMxh0BI 7EhsO4SfDI3ZnYFJvAEMrTvgY8Vz4v817LhzWNZ7RWxq/yOHG8C/ZgubPJIa8mnd EGWUVoLg77E= =OJHh -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
Re: [Python-Dev] Community buildbots and Python release quality metrics
On Thu, Jun 26, 2008 at 12:35 PM, <[EMAIL PROTECTED]> wrote: > > On 05:14 pm, [EMAIL PROTECTED] wrote: >>> >>> I don't know. JP is already addressing the issues affecting Twisted in >>> another thread (incompatible changes in the private-but-necessary-to- >>> get-any-testing-done API of the warnings module). But I really think >>> that whoever made the change which broke it should be the one >>> investigating it, not me. >> >> How could they have known that they broke it? > > Because the relevant community buildbot turned red with that revision of > trunk. Keep in mind I'm not talking about every piece of Python code in the > universe; just the ones selected for the community buildbots. It would be > nice if there were a dozen or so projects on there, but paying attention to > the two builders that do actually run right now would be a good start. Sorry, this is an unacceptable burden on the core developers. The core developers aren't going to look at the community buildbots (unless voluntarily) and they aren't going to roll back changes just because some community buildbot goes red. In general someone outside the core developer group needs to bring the issue to the core developers' attention and then a fix will be created if appropriate. Rollbacks are generally reserved for accidental checkins or checkins against the process rules (e.g. during a code freeze). Heck, we don't even roll back if one of our own buildbots goes red. I'm fine with requesting that the core developers pay serious attention to reports about 3rd party code being broken. The community buildbots are a fine tool to find out about this. But any policy that requires an automatic rollback because a buildbot (community or core) goes red is unacceptable. -- --Guido van Rossum (home page: http://www.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] Community buildbots and Python release quality metrics
Barry Warsaw schrieb: I don't know if this "Barry" guy has the appropriate permissions on the bugtracker to increase priorities, so I've taken the liberty of upgrading it as a release blocker for the _second_ beta ... ;-). So, at least there's been one productive consequence of this discussion. Glyph, you did the right thing. I wish there was a way of marking a bug "not-release-blocker-for-now" and have it automatically update back to blocker at a certain time or after a certain event. I think it's valid for this issue to block beta2. I just added a "deferred blocker" priority -- that implements one half of your wish. Mass issue updating must be done by someone who knows Roundup better than me, I'm afraid. Georg ___ 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] Community buildbots and Python release quality metrics
On Thu, Jun 26, 2008 at 1:06 PM, <[EMAIL PROTECTED]> wrote:
> On 07:44 pm, [EMAIL PROTECTED] wrote:
>>
>> At no time will a policy "the community buildbots must be green" be
>> useful: the tests that run on these buildbots are not under our control,
>> so if the tests test things we deem non-public we can't do anything
>> about it. (And we may have a hard time convincing project authors to
>> change the tests if we promised to make them run anyway.)
>
> That's not what I'm suggesting.
>
> If there is a legitimate disagreement between Python developers and
> developers of a project about whether an API should continue to be
> supported, then clearly, the Python developers get to win. Welcome to open
> source.
>
> However, I believe that the core team is not paying attention to other
> projects breaking. I'm not saying that you want to make breaking changes,
> or that bug reports are not dealt with, but the problem is that dealing with
> these problems after the fact makes it _much_ more painful. When you get to
> the release, and you have 30 bug reports due to other projects breaking,
> they get triaged, some get left in, and some features of lots of different
> projects are left broken. And many projects do not bother to test with the
> beta.
Well, sorry, that's life. We're not going to deal with breakage in 3rd
party code on a "drop all other work" basis.
You seem to have a different idea about how to do development than the
core developers. Tough luck. You can't tell us how to do our work.
We're doing the best we can, and we're happy to listen to suggestions
you're making, but the set of suggestions you're making in this thread
are an unacceptable burden, and it's not going to happen.
> If developers were simply presented with the results of their changes
> immediately ("you broke twisted, django doesn't import, zope segfaults and
> mercurial destroys your repository") then perhaps they would weigh the
> benefits of compatibility differently, and do the trivial, obvious fix
> immediately, rather than waiting 6 months and having to figure out what the
> heck change caused the bug. I accept the fact that python core development
> is done differently than i.e. Java development, and some backward
> compatibility may simply be broken.
>
> Case in point: changes to the warnings module being discussed in a separate
> thread break a significant number of Twisted's tests, because they remove
> functionality which is not public but is required to test code that uses the
> warnings module. Would Brett have taken this into account if he knew about
> it immediately when revision 62303 was committed? Maybe not, but now that
> the code is written and done, there's significantly less motivation to go
> back and fix it.
I disagree. It's broken and should be fixed. Beta 1 just came out so
this is the perfect time to file a bug.
> At the time it might have only been a few minutes' work to
> continue supporting the use-case which Twisted needs. Brett wouldn't even
> have necessarily needed to do the work: it would have been easier to
> convince a Twisted developer to do the work it to keep the community
> buildbot green rather than to make it a bit less red.
Why? That sounds like it's a problem with the psychology of the
Twisted developers.
> Now, though, it's
> much easier to say "oh well, that's private, you lose". I don't ascribe
> this to malice - it really *would* be much harder to fix it now, for us as
> well as for him.
I don't believe this.
--
--Guido van Rossum (home page: http://www.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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
On Thu, Jun 26, 2008 at 9:55 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
>
> It's disadvantage from Python's point of view is that some features are IEEE
> 754
Aargh! I can't believe I wrote that. Its. Its. Its. Anyway; some
more detail:
Both C99 and Java 1.5/1.6 support hex floating-point literals; both
in exactly the
same format, as far as I can tell. Here are the relevant productions
from the Java
grammar:
HexDigit: one of
0 1 2 3 4 5 6 7 8 9 a b c d e f A B C D E F
HexNumeral:
0 x HexDigits
0 X HexDigits
HexDigits:
HexDigit
HexDigit HexDigits
HexadecimalFloatingPointLiteral:
HexSignificand BinaryExponent FloatTypeSuffix_opt
HexSignificand:
HexNumeral
HexNumeral .
0x HexDigits_opt . HexDigits
0X HexDigits_opt . HexDigits
BinaryExponent:
BinaryExponentIndicator SignedInteger
BinaryExponentIndicator:one of
p P
Java's 'Double' class has a 'toHexString' method that
outputs a valid hex floating point string, and the Double()
constructor also accepts such strings.
C99 also appears to have full support for input/output
of hex floats; e.g. using strtod and printf('%a', ...).
Not sure how helpful this is.
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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
On Thu, Jun 26, 2008 at 1:46 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote: > I'd be delighted with '%a' support. Remind me what %a does? -- --Guido van Rossum (home page: http://www.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] [Python-checkins] r64424 - inpython/trunk:Include/object.h Lib/test/test_sys.pyMisc/NEWSObjects/intobject.c Objects/longobject.cObjects/typeobject.cPython/bltinmodule.c
[MvL] Then I'd argue that the feature should be symmetric: If there is support for printing floating point numbers as hex, there should also be support for hex floating point literals. [Mark] I agree with this. Or at least support for hex floating point strings, if not literals. ISTM, that the currently proposed output format gives us this benefit for free (no changes to the parser). The format is already close to the C99 notation but replaces the 'p' with '* 2.0 **' which I find to be both readable and self-explanatory. 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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
> I think the above it still a bit easier to understand than > if one has to figure out where the sign/exponent and > exponent/fraction bit boundaries are, unbias the exponent, > and add the extra hidden '1' bit into the mantissa. That's > a lot of mental work. Sure. However, I'd argue that most people are unable to even remotely guess the number in decimal when presented with the number in hexadecimal - at a minimum, they'll fail to recognize that the exponent is not to the power of 10, or when they realize that, might guess that it is to the power of 16 (I find it fairly confusing, but consequential, that it is to the power of 2, even when the digits are hex - and then, the exponent is decimal :-). So I'd like to dismiss any objective of "the output must be human-understandable" as unrealistic. That an unambiguous representation is desired, I can understand - but only if there also is a way to enter the same representation elsewhere. In addition, I fail to see the point in binary representation. For unambiguous representation, it's sufficient to use hex. I can't accept claims that people will be actually able to understand what number is represented when given the bit string. For educational purposes, decoding mantissa and biased exponent directly out of the IEEE representation is better than having binary output builtin. > Also, to follow C's tradition, it would be better if that was > *not* integrated into the hex function (or a hex method), but > if there was support for %a in string formatting. > > > I'd be delighted with '%a' support. I personally find that much less problematic than extending the hex, and wouldn't object to a patch providing such formatting (assuming it does the same thing that C99 printf does). 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] Community buildbots and Python release quality metrics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 26, 2008, at 5:20 PM, Georg Brandl wrote: Barry Warsaw schrieb: I don't know if this "Barry" guy has the appropriate permissions on the bugtracker to increase priorities, so I've taken the liberty of upgrading it as a release blocker for the _second_ beta ... ;-). So, at least there's been one productive consequence of this discussion. Glyph, you did the right thing. I wish there was a way of marking a bug "not-release-blocker-for-now" and have it automatically update back to blocker at a certain time or after a certain event. I think it's valid for this issue to block beta2. I just added a "deferred blocker" priority -- that implements one half of your wish. Mass issue updating must be done by someone who knows Roundup better than me, I'm afraid. Cool, thanks! I should have thought of that before. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSGQNm3EjvBPtnXfVAQIy1wP/QPFwklmnay8VPPovHA6H4XA6tW+ziWPV hbeyAZX/MMxEYv/98Z4nOQU7M4AczlXHZks80UvDdKLwPe2wTwfOIgmCTeb+vciI 20GpxrHpWQNHy/XKeawEBxyLHJZ4qNGIAFmHwoiUusM6erTeVb9kWa0czG31En6r Z4MV0YKfu+A= =Zxh4 -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
Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
Guido van Rossum wrote: > On Thu, Jun 26, 2008 at 1:46 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote: >> I'd be delighted with '%a' support. > > Remind me what %a does? It's a C99 feature. From the spec (7.19.6.1p8) a,A A double argument representing a floating-point number is converted in the style [-]0xh.p±d, where there is one hexadecimal digit (which is nonzero if the argument is a normalized floating- point number and is otherwise unspecified) before the decimal-point character235) and the number of hexadecimal digits after it is equal to the precision; if the precision is missing and FLT_RADIX is a power of 2, then the precision is sufficient for an exact representation of the value; if the precision is missing and FLT_RADIX is not a power of 2, then the precision issufficientto distinguish236) values of type double, except that trailing zeros may be omitted; if the precision is zero and the # flag is not specified, no decimal- point character appears. The letters abcdef are used for a conversion and the letters ABCDEF for A conversion. The A conversion specifier produces a number with X and P instead of x and p. The exponent always contains at least one digit, and only as many more digits as necessary to represent the decimal exponent of 2. If the value is zero, the exponent is zero. A double argument representing an infinity or NaN is converted in the style of an f or F conversion specifier. Footnotes 235) Binary implementations can choose the hexadecimal digit to the left of the decimal-point character so that subsequent digits align to nibble (4-bit) boundaries. 236) The precision p is sufficient to distinguish values of the source type if 16p-1>bn where b is FLT_RADIX and n is the number of base-b digits in the significand of the source type. A smaller p might suffice depending on the implementation's scheme for determining the digit to the left of the decimal-point character. This is symmetric with C99's hexadecimal floating point literals: hexadecimal-floating-constant: hexadecimal-prefix hexadecimal-fractional-constant binary-exponent-part floating-suffix-opt hexadecimal-prefix hexadecimal-digit-sequence binary-exponent-part floating-suffix-opt hexadecimal-fractional-constant: hexadecimal-digit-sequence-opt . hexadecimal-digit-sequence hexadecimal-digit-sequence . binary-exponent-part: p sign-opt digit-sequence P sign-opt digit-sequence hexadecimal-digit-sequence: hexadecimal-digit hexadecimal-digit-sequence hexadecimal-digit scanf and strtod support the same format. 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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
On Thu, Jun 26, 2008 at 10:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Remind me what %a does? From the C99 standard (section 7.19.6.1): A double argument representing a floating-point number is converted in the style [−]0xh.p±d, [...] ___ 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-checkins] r64424 - inpython/trunk:Include/object.h Lib/test/test_sys.pyMisc/NEWSObjects/intobject.c Objects/longobject.cObjects/typeobject.cPython/bltinmodule.c
On Thu, Jun 26, 2008 at 10:30 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > ISTM, that the currently proposed output format gives > us this benefit for free (no changes to the parser). The format is already > close to the C99 notation but replaces the 'p' with '* 2.0 **' which I find > to > be both readable and self-explanatory. There's one other major difference between the C99 notation and the current patch: the C99 notation includes a (hexa)decimal point. The advantages of this include: - the exponent gives a rough idea of the magnitude of the number, and - the exponent doesn't vary with changes to the least significant bits of the float. The disadvantage is the loss of evalability. (Is that a word?) 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] Community buildbots and Python release quality metrics
> I just added a "deferred blocker" priority -- that implements one half > of your wish. Mass issue updating must be done by someone who knows > Roundup better than me, I'm afraid. I doubt true mass update will be necessary. If you remind me that I should convert all "deferred blocker" issues to some other priority, I'll do that manually in a matter of minutes (using a query to find all issues with that priority). 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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
Mark Dickinson schrieb: On Thu, Jun 26, 2008 at 10:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: Remind me what %a does? From the C99 standard (section 7.19.6.1): A double argument representing a floating-point number is converted in the style [−]0xh.p±d, [...] Let me remind you that %a currently means "call ascii()" in 3.0. Georg ___ 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-checkins] r64424 - inpython/trunk:Include/object.h Lib/test/test_sys.pyMisc/NEWSObjects/intobject.c Objects/longobject.cObjects/typeobject.cPython/bltinmodule.c
> The disadvantage is the loss of evalability. (Is that a word?) Until the parser has support for it, having a float class method, or even the float callable itself for conversion seems reasonable. If repr() didn't produce it, eval() doesn't need to understand it. 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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
Raymond Hettinger wrote: From: "Guido van Rossum" <[EMAIL PROTECTED]> Let's step back and discuss the API some more. - Do we need all three? I think so -- see the the reasons below. I would prefer 1, see below. Of course, my first choice was not on your list. To me, the one obvious way to convert a number to a eval-able string in a different base is to use bin(), oct(), or hex(). But that appears to be off the table for reasons that I've read but don't make any sense to me. Let me try. I am one of those who prefer smaller to bigger for the core language to make it easier to learn and teach. But, to me, there deeper consideration that applies here. A Python interpreter, human or mechanical, must do exact integer arithmetic. But a Python interpreter does not have to convert float literals to fixed size binary and does *not* have to do float arithmetic with binary presentations that are usually approximations. (Indeed, human interpreters do neither, which is why they are often surprised at CPython's float output, and which is why this function will be useful.) If built-in functions are part of the language definition, as Guido just clarified, their definition and justification should not depend on the float implementation. It seems simple enough, extendable enough, and clean enough for bin/oct/hex to use __index__ if present and __float__ if not. To me, a binary representation, in whatever base, of a Decimal is senseless. The point of this issue is to reveal the exact binary bit pattern of float instances. - If so, why not .tobase(N)? (Even if N is restricted to 2, 8 and 16.) I don't think it's user-friendly to have the float-to-bin API fail to parallel the int-to-bin API. IMO, it should be done the same way in both places. I would like to turn this around. I think that 3 nearly identical built-ins is 2 too many. I am going to propose on the Py3 list that bin, oct, and hex be condensed to one function, bin(integer, base=2,8,or16), for 3.1 if not 3.0. Base 8 and 16 are, to me, compressed binary. Three methods is definitely too many for a somewhat subsidiary function. So, I would like to see float.bin([base=2]) I don't find it attractive in appearance. Any use case I can imagine involves multiple calls using the same base and I would likely end-up using functools.partial or somesuch to factor-out the repeated use of the same variable. Make the base that naive users want to see the default. I believe this to be 2. Numerical analysts who want base 16 can deal with partial if they really have scattered calls (as opposes to a few within loops) and cannot deal with typing '16' over and over. bin(.6) '0b10011001100110011001100110011001100110011001100110011 * 2.0**-53' ... Both of those bits of analysis become awkward with the tobase() method: (.6).tobase(2) Eliminate the unneeded parentheses and default value, and this is >>> .6.bin() which is just one extra char. - What should the output format be? I know you originally favored 0b10101.010101 etc. Now that it's not overloaded on the bin/oct/hex builtins, the constraint that it needs to be an eval() able expression may be dropped (unless you see a use case for that too). The other guys convinced me that round tripping was important and that there is a good use case for being able to read/write precisely specified floats in a platform independent manner. Definitely. The paper I referenced in the issue discussion, http://bugs.python.org/issue3008 mentioned a few times here, is http://hal.archives-ouvertes.fr/docs/00/28/14/29/PDF/floating-point-article.pdf Also, my original idea didn't scale well without exponential notation -- i.e. bin(125E-100) would have a heckofa lot of leading zeroes. Terry and Mark also pointed-out that the hex with exponential notation was the normal notation used in papers on floating point arithmetic. Lastly, once I changed over to the new way, it dramatically simplified the implementation. I originally thought I preferred the 'hexponential' notation that uses P for power instead of E for exponential. But with multiple bases, the redundancy of repeating the bases is ok, and being able to eval() without changing the parser is a plus. But I would prefer losing the spaces around the ** operator. 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] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
On Thu, Jun 26, 2008 at 11:00 PM, Georg Brandl <[EMAIL PROTECTED]> wrote: > Let me remind you that %a currently means "call ascii()" in 3.0. Oh well. That's out then. I'll rephrase to "I'd be delighted with something similar in spirit to '%a' support." :-) 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] Py3k DeprecationWarning in stdlib
On Thu, Jun 26, 2008 at 9:01 AM, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > On Fri, 27 Jun 2008 01:52:18 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> >> Jean-Paul Calderone wrote: >>> >>> I don't particularly care about the details, I just want some public >>> API for this. Making warn_explicit public seems better to me, since >>> it was already there in previous versions of Python, and it lets you >>> completely ignore both the filters list and the global registry, but >>> if others would rather make the filters and global registry a part of >>> the public API, that's fine by me as well. >> >> Why do you say warn_explicit isn't public? It's in both the 2.5 and 2.6 >> API docs for the warnings module. > > Brett told me it was private (on this list several weeks or a month or so > ago). It's also no longer called in 2.6 by the C implementation of the > warning system. > I don't remember saying it is private, just that you can't replace the function in the module and expect everything to continue to work properly like you can with showwarning(). -Brett ___ 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-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
On Thu, Jun 26, 2008 at 11:00 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: > Definitely. The paper I referenced in the issue discussion, > http://bugs.python.org/issue3008 mentioned a few times here, is > http://hal.archives-ouvertes.fr/docs/00/28/14/29/PDF/floating-point-article.pdf Perhaps it's worth reproducing the most relevant paragraph of that paper (the end of section 2.1) here: """Conversion to and from decimal representation is delicate; special care must be taken in order not to introduce inaccuracies or discrepan- cies. [Steele and White, 1990, Clinger, 1990]. Because of this, C99 introduces hexadecimal floating-point literals in source code. [ISO, 1999, §6.4.4.2] Their syntax is as follows: 0xmm.p±ee where mm. is a mantissa in hexadecimal, possibly containing a point, and ee is an exponent, written in deci- mal, possibly preceded by a sign. They are interpreted as [mm.]16×2ee . Hexadecimal floating-point representations are especially important when val- ues must be represented exactly, for reproducible results — for instance, for testing "borderline cases" in algorithms. For this reason, we shall use them in this paper wherever it is important to specify exact values. See also Section 4.4 for more information on inputting and outputting floating-point values.""" ___ 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] Community buildbots and Python release quality metrics
On Thu, Jun 26, 2008 at 8:45 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > So you're saying py.test needs to be fixed? Fine with me, but then I > don't understand why you bothered bringing it up here instead of > fixing it (or reporting to the py.test maintainers, I don't know if > you're one or not). > no, I'm not. Just wanted to point out, that this ticket/patch does not solve the django issue. (this is what I first thought it would do). - Ralf ___ 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-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
Mark Dickinson wrote: On Thu, Jun 26, 2008 at 11:00 PM, Georg Brandl <[EMAIL PROTECTED]> wrote: Let me remind you that %a currently means "call ascii()" in 3.0. Oh well. That's out then. I'll rephrase to "I'd be delighted with something similar in spirit to '%a' support." :-) It could be added to str.format(). Well, actually float.__format__(). Not that I'm advocating it, but it's a place it would fit, and since it's restricted to the float format specifier, it would at least be well contained. And other types are free to implement it, or not. ___ 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] Community buildbots and Python release quality metrics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 26, 2008, at 5:54 PM, Martin v. Löwis wrote: I just added a "deferred blocker" priority -- that implements one half of your wish. Mass issue updating must be done by someone who knows Roundup better than me, I'm afraid. I doubt true mass update will be necessary. If you remind me that I should convert all "deferred blocker" issues to some other priority, I'll do that manually in a matter of minutes (using a query to find all issues with that priority). Martin, I think that will work great. The idea being that after each release, we always bump deferred blockers back to release blocker. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSGQZbHEjvBPtnXfVAQIwWQQAqWoIoqV0S0O8ZpkXpWd3LO4Fo7MBfjRT LL5QgIPBWdQdZ4RR68LSfdAhiHGnZCZorpNksGaeIxP55qgS1z31fy3JF39UUbVR 3ojymtF6Is0qCB5lmkJIx9Na/2RUEOUWTQoQP3dG851oRRuSVTXb4uRaBlNlQErY oN9JxG5xQR0= =z9nN -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
Re: [Python-Dev] [Python-checkins] r64424 - inpython/trunk:Include/object.h Lib/test/test_sys.pyMisc/NEWSObjects/intobject.c Objects/longobject.cObjects/typeobject.cPython/bltinmodule.c
On Fri, 27 Jun 2008 07:30:43 am Raymond Hettinger wrote: > The format is already close to the C99 notation > but replaces the 'p' with '* 2.0 **' which I find to > be both readable and self-explanatory. Since we're talking about what's "readable and self-explanatory", I find that jarring, unexpected, unintuitive, and mathematically bizarre (even if it is the convention in some areas). It's like writing '123 * A.0 ** -2' for 1.23. And putting spaces around the operators is ugly. I'd like to mention that what bin() et al is actually doing is not so much returning a binary number string but returning a hybrid binary/decimal arithmetic expression. So bin() returns a binary number string for int arguments, and an expression for float arguments: these are conceptually different kinds of things, even if they're both strings. Frankly, I'd be much happier if the API (whatever it is) returned a tuple of (binary string, base int, exponent int), and let users write their own helper function to format it any way they like. Or failing that, the p notation used by Java and C99. (And yes, mixing decimal exponents with binary mantissas upsets me too, but somehow it's less upsetting.) -- Steven ___ 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
