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
used.
[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 C to
-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
behavior to me as a person
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
[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 input?
[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.
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 better.
I
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 a
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 no
|
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 new
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.
'bytearray' is
'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
Incodentally, I think your example is wrong. It should be either
psql /dev/null 21
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 Thu, 24
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?
--
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) /
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() would
[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:
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 with
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 of and
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
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 in
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
||
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 did say
. 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
25 matches
Mail list logo
