I don't want the discussion in the issue. I want to have it right here.
While I think it's fine to have some function that reveals the binary
representation of floats, I don't think that overlaying this on
hex/oct/bin is worth the problems it causes. This API appears to be
purely for educational p
Issue 3008 has been re-opened for more commentary.
Raymond
- Original Message -
From: "Guido van Rossum" <[EMAIL PROTECTED]>
Since it's (potentially) a pretty small feature I might be convinced
to accept it in beta2, but I don't want the fact that it was committed
to force our hand. Ra
On Tue, 24 Jun 2008 23:03:33 -, [EMAIL PROTECTED] wrote:
On 10:05 pm, [EMAIL PROTECTED] wrote:
We need to be especially careful with the unit test suite itself - changing
the test code to avoid the warning will normally be the right answer, but
when the code is actually setting out to test
On 10:05 pm, [EMAIL PROTECTED] wrote:
We need to be especially careful with the unit test suite itself -
changing the test code to avoid the warning will normally be the right
answer, but when the code is actually setting out to test the
deprecated feature we need to suppress the warning in the
Benjamin Peterson wrote:
On Tue, Jun 24, 2008 at 11:42 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
The same generic warning against sweeping changes applies here though.
You have to manually review each change. The stdlib and especially the
test suite is likely to break if you just let 2to3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 24, 2008, at 4:13 PM, Guido van Rossum wrote:
[Mark Dickinson]
I think there may also still be room for some additional discussion
on the output format;
[Martin v. Löwis]
If so, I think the change should be reverted, and the feature
defe
[Mark Dickinson]
>> I think there may also still be room for some additional discussion
>> on the output format;
[Martin v. Löwis]
> If so, I think the change should be reverted, and the feature deferred
> to 2.7/3.1.
It looks like pretty much every aspect of this change was discussed /
reviewed
> I think there may also still be room for some additional discussion
> on the output format;
If so, I think the change should be reverted, and the feature deferred
to 2.7/3.1.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
On Tue, Jun 24, 2008 at 11:42 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The same generic warning against sweeping changes applies here though.
> You have to manually review each change. The stdlib and especially the
> test suite is likely to break if you just let 2to3 run over it, even
> ju
On Tue, Jun 24, 2008 at 8:05 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> Following the discussion in the issue tracker is really hard (since
> most of the discussion apparently refers to earlier versions). I also
> don't see any doc changes.
I think there may also still be room for some
I'm curious why the addition of a new feature, past beta 1, was
constrained entirely to a single tracker issue. Clearly not enough
people were aware of it (or there wouldn't be the discussion about it
here).
Following the discussion in the issue tracker is really hard (since
most of the discussion
On Tue, Jun 24, 2008 at 10:07 AM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>>>
>>> The 3.0 approach means that non-float floating point types still can't be
>>> displayed properly by bin()/oct()/hex().
>>
>> Nor can float, AFAICT from the current 3.0 tree.
>
> $ ./python
> Py
Martin v. Löwis wrote:
I'm just doing some housekeeping on a Windows install, and notice that
the 'Publisher' of my Python 2.4 and 2.5 installs is shown as "Martin v.
Lowis". Whilst I *personally* find this very reassuring I wonder if this
is intended / ideal?
I certainly intended it: the
> I'm just doing some housekeeping on a Windows install, and notice that
> the 'Publisher' of my Python 2.4 and 2.5 installs is shown as "Martin v.
> Lowis". Whilst I *personally* find this very reassuring I wonder if this
> is intended / ideal?
I certainly intended it: the field really is called
Guido van Rossum wrote:
The 3.0 approach means that non-float floating point types still can't be
displayed properly by bin()/oct()/hex().
Nor can float, AFAICT from the current 3.0 tree.
$ ./python
Python 3.0b1+ (py3k:64491:64497M, Jun 24 2008, 07:14:03)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13
Hello,
It has been some time since some discussion happened on
http://bugs.python.org/issue2240, and I intended to compose this email
several days ago but just did it now.
This is an attempt to find someone who might have some
information/idea that could help solving the current problem regarding
On Tue, Jun 24, 2008 at 6:17 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Eric Smith wrote:
>>
>> Note that in
>> http://mail.python.org/pipermail/python-dev/2008-February/077062.html, Guido
>> advocates not adding the __bin__ machinery, which is what lead to the simple
>> implementation of bin()
The same generic warning against sweeping changes applies here though.
You have to manually review each change. The stdlib and especially the
test suite is likely to break if you just let 2to3 run over it, even
just a single fixer like fix_has_key.
On Tue, Jun 24, 2008 at 6:11 AM, Benjamin Peterso
On Tue, 24 Jun 2008, Nick Coghlan wrote:
> I'd prefer to see a proper PEP for this proposing a new slot that lets any
> class return an (integer_part, fraction_part) tuple of integers, and
> have PyNumber_ToBase take care of the actual string formatting.
I take issue only with your notion of retu
From: "Nick Coghlan" <[EMAIL PROTECTED]>
The 3.0 approach means that non-float floating point types still can't be displayed properly by bin()/oct()/hex(). The current 2.6
approach means every such class has to implement its own equivalent of PyNumber_ToBase.
Feel free to change the implementat
Eric Smith wrote:
Note that in
http://mail.python.org/pipermail/python-dev/2008-February/077062.html,
Guido advocates not adding the __bin__ machinery, which is what lead to
the simple implementation of bin() just calling PyNumber_ToBase and
relying on __index__.
I don't think __bin__ should
On Tue, Jun 24, 2008 at 8:08 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Benjamin Peterson wrote:
>>
>> On Tue, Jun 24, 2008 at 5:34 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>>
>>> I'd say so, yes. If tracker issues don't exist yet, please create them.
>>> The
>>> focus for the first beta was
Benjamin Peterson wrote:
On Tue, Jun 24, 2008 at 5:34 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
I'd say so, yes. If tracker issues don't exist yet, please create them. The
focus for the first beta was really on getting all the syntax and API
changes stable - the remaining time between the firs
On Tue, Jun 24, 2008 at 5:34 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I'd say so, yes. If tracker issues don't exist yet, please create them. The
> focus for the first beta was really on getting all the syntax and API
> changes stable - the remaining time between the first beta release and the
Michael Foord wrote:
Hello all,
I'm just doing some housekeeping on a Windows install, and notice that
the 'Publisher' of my Python 2.4 and 2.5 installs is shown as "Martin
v. Lowis". Whilst I *personally* find this very reassuring I wonder if
this is intended / ideal?
Just to clarify, this
Hello all,
I'm just doing some housekeeping on a Windows install, and notice that
the 'Publisher' of my Python 2.4 and 2.5 installs is shown as "Martin v.
Lowis". Whilst I *personally* find this very reassuring I wonder if this
is intended / ideal?
All the best,
Michael Foord
__
On Tue, Jun 24, 2008 at 12:34 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Probably because nobody has stepped up to write a migration HOWTO yet...
I'm not much of a writer, but once I'm finished with the migration,
I'll do it (if it hasn't been done then). It's about time I try to
learn reST...
Virgil Dupras wrote:
Hi Devs,
Today, I saw the Py3k beta 1 announcement, so I thought "Well, I gotta
do my duty and try to migrate my own code base to see if I can uncover
any problems". I'm just at the step where I run my test suite with the
"-3" flag, and I noticed something peculiar: I get De
Hi Devs,
Today, I saw the Py3k beta 1 announcement, so I thought "Well, I gotta
do my duty and try to migrate my own code base to see if I can uncover
any problems". I'm just at the step where I run my test suite with the
"-3" flag, and I noticed something peculiar: I get DeprecationWarning
from s
Martin v. Löwis v.loewis.de> writes:
>
> I'd like to see in an experiment whether this is really true.
Right, all those ideas should be implemented and tried out. I don't really have
time to spend on it right now.
Also, what's missing is a suite of performance/efficiency tests for the garbage
30 matches
Mail list logo
