On 26 Jun, 09:24 pm, [EMAIL PROTECTED] wrote:
On Thu, Jun 26, 2008 at 1:06 PM, <[EMAIL PROTECTED]> wrote:
On 07:44 pm, [EMAIL PROTECTED] wrote:
Well, sorry, that's life. We're not going to deal with breakage in 3rd
party code on a "drop all other work" basis.
For the record, "automatic rev
Raymond Hettinger wrote:
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().
What use cases are there for an eval-able representation
of a float in those bases, as opposed to a human-readable
one?
--
Greg
We need two counters: one is the total number of traceable objects
(those we would inspect if we did a full collection) and a number of
"pending" trace operations. Every time an object is moved into the
last generation, we increase "pending" by two - once for itself and
once for an older object.
On 09:17 pm, [EMAIL PROTECTED] wrote:
On Thu, Jun 26, 2008 at 12:35 PM, <[EMAIL PROTECTED]> wrote:
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 c
Jeff Hall wrote:
I mistakenly thought that was
because they were assumed to be small. It sounds like they're ignored
because they're automatically collected and so they SHOULD be ignored
for object garbage collection.
Strings aren't tracked by the cyclic garbage collector
because they don't 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, unexpec
-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
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
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
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'
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_
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
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 wa
> 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
__
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 tha
> 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 s
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
> b
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, [...]
___
P
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
-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 f
> 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
[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, tha
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
Python-Dev@python.org
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-poi
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-publi
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
disc
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 warni
-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 com
-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 o
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'
>
>
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/java
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
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 behavi
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, stabl
[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 ma
[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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
>
> 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
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 a
> 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 woul
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 ass
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
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 AP
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 convincin
> 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
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'"?
Her
[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 syst
> 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
__
>> 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
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
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
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
hand
[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 b
[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 way
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 s
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'
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... :)
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-
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
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.
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 meth
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 patc
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-
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 di
> 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/
> 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
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 PR
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
> i
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/
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
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
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 mo
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 disablin
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, an
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
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 metho
[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 possibl
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
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
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
acknowledg
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")
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
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 trac
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 th
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 -- everyo
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
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 th
-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 w
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 us
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
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
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 doub
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 u
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 funct
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 reca
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
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
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 jus
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 e
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 pat
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 f
1 - 100 of 105 matches
Mail list logo
