>. You may disagree, but that doesn't make it nuts.
Too many thoughts compressed into one adjective ;-)
Deprecating int(float)-->int may not be nuts, but it is disruptive.
Having both trunc() and int() in Py2.6 may not be nuts, but it is duplicative
and confusing.
The original impetus for faci
On Jan 26, 2008 2:53 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
[Jeffrey]
> > I've been
> > advocating trunc() under the assumption that int(float) would be
> > deprecated and eliminated as soon as practical
>
> And how much code would break for basically zero benefit?
We'll see. Jeffrey di
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Raymond Hettinger wrote:
| > A prefix would be better.
|
| I initially thought that, but found the suffix to be the least annoying
| of the ideas I had for denoting abstract base classes. To try and give
|| INumber
|| AB
"Jeffrey Yasskin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|| To elaborate the point I was trying to make: If float() does not mean
| "the float part of"
The 'float part' of a complex number is meaningless since both components
of a complex are floats (in practice, or reals i
Around Jan 13, the refleak hunting test that is reported on
python-checkins started to report refleaks on virtually every run. I
suspect this is due to r59944 (at 2008-01-13 16:29:41) which was from
patch #1700288 to cache methods. With this patch it makes it much
harder to spot refleaks. Does a
On Jan 26, 2008 2:46 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Christian Heimes]
> > In my opinion float(complex) does do the most sensible thing. It fails
> > and points the user to abs().
>
> Right.
To elaborate the point I was trying to make: If float() does not mean
"the float part o
> I've been
> advocating trunc() under the assumption that int(float) would be
> deprecated and eliminated as soon as practical
And how much code would break for basically zero benefit?
This position is totally nuts.
There is *nothing* wrong with int() as it stands now. Nobody has
problems wit
[Christian Heimes]
> In my opinion float(complex) does do the most sensible thing. It fails
> and points the user to abs().
Right.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Jan 26, 2008 12:43 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> That, and making int(float) == int(trunc(float)) seems like reasonable
> behavior to me as a person not involved in the discussion.
That's the only position in this discussion that I don't understand.
Although int() and trunc() wo
Jeffrey Yasskin wrote:
> This interpretation implies that complex should provide __float__() to
> return the non-imaginary portion of a complex number. Is that what you
> intend?
No, please don't. If somebody wants to implement __float__ for complex
numbers please define it as hypot(complex) / sqr
On Jan 25, 2008 11:21 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> ... int() for making ints from the non-fractional
> portion of a float.
This interpretation implies that complex should provide __float__() to
return the non-imaginary portion of a complex number. Is that what you
intend?
-
Incodentally, I think your example is wrong. It should be either
psql >/dev/null 2>&1
or
psql &>/dev/null
Notice the reversal of redirects in the first one.
Of course, this doesn't change anything about the core discussion...
- C
On 1/24/08, Isaac Morland <[EMAIL PROTECTED]> wrote:
> On T
> 'bytearray' is a separate issue. It's a brand new type: a *mutable*
> byte array. Its status as a built-in and completely different API
> makes it much more convenient than using the old array module.
That's reasonable.
Raymond
___
Python-Dev mailing
Guido van Rossum wrote:
> On Jan 26, 2008 1:16 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>> Are you planning to backport bytearrays?
>> I thought we had clearly decided to *not* backport any of the text/bytes
>> model so that the
>> Py2.6 string/unicode model remained pure.
>>
>
>
On Jan 26, 2008 1:16 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Are you planning to backport bytearrays?
> I thought we had clearly decided to *not* backport any of the text/bytes
> model so that the
> Py2.6 string/unicode model remained pure.
'bytearray' is a separate issue. It's a brand
On Jan 25, 2008 10:50 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> "Jameson "Chema" Quinn" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | I'm writing a source code editor that translates identifiers and keywords
> | on-screen into a different natural language. This tool will do n
Raymond Hettinger wrote:
> Are you planning to backport bytearrays? I thought we had clearly decided to
> *not* backport any of the text/bytes model so that the
> Py2.6 string/unicode model remained pure.
The idea raised when I was working on a backport of the io module. The
io module requires
Raymond Hettinger wrote:
>> but if Guido likes the idea of a standard naming convention (such as
>> the ABC suffix) for classes that use the ABCMeta metaclass, I'd
>> certainly be happy to go through and update the affected classes and
>> the code which refers to them.
>
> A prefix would be bet
[EMAIL PROTECTED] wrote:
> Sorry if this is a repeat. I don't remember seeing this in the various
> Python-related stuff I've received before (and no longer monitor c.l.py,
> only look at the weekly summary), though based on the dateline of the
> Slashdot item I saw (Jan 9) it should be old news.
Terry Reedy wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | Does no-one thinks it means round(f) either?
>
> Not me. Int should truncate, so trunc() not needed unless is does
> something different.
>
Like returning a value of the same type as the i
[EMAIL PROTECTED] wrote:
> Sorry if this is a repeat. I don't remember seeing this in the various
> Python-related stuff I've received before (and no longer monitor c.l.py,
> only look at the weekly summary), though based on the dateline of the
> Slashdot item I saw (Jan 9) it should be old news.
Sorry if this is a repeat. I don't remember seeing this in the various
Python-related stuff I've received before (and no longer monitor c.l.py,
only look at the weekly summary), though based on the dateline of the
Slashdot item I saw (Jan 9) it should be old news. Apparently, in 2007
Python surg
-On [20080126 09:43], Georg Brandl ([EMAIL PROTECTED]) wrote:
>Paul Moore schrieb:
>> - int() has to stay in builtins for obvious reasons.
>> - put *all* of trunc, ceil, floor, round into math.
>
>That, and making int(float) == int(trunc(float)) seems like reasonable
>be
[christian.heimes]
>> Backport of several functions from Python 3.0 to 2.6 including
>> PyUnicode_FromString, PyUnicode_Format and PyLong_From/AsSsize_t.
>> The functions are partly required for the backport of the bytearray type and
>> _fileio module. They should also make it easier to
>> port
Paul Moore schrieb:
> On 24/01/2008, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
>> int has to be a builtin because it's a fundamental type. trunc()
>> followed round() into the builtins. I have no opinion on whether ceil
>> and floor should move there; it probably depends on how often they're
>> us
25 matches
Mail list logo
