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
[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
-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
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
[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.
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
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
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
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
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 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 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
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) / sqr
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
[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 wit
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
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
"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
"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
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
>. 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
25 matches
Mail list logo
