Raymond Hettinger wrote:
> Please ignore my last email. The idea for combining trunc, ceil,
> floor, etc was probably just a distractor.
I was going to suggest the same round(n, mode="round_method_of choice") to
both round and int(), where int is more forgiving for input. But wasn't
convince
> What do you think of the above?
Sounds fine to me. I won't touch this then for the moment,
please let me know when you are done rearranging things.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
On Jan 27, 2008 3:37 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> The actual claim seems to have been that the semantics of int()
> itself is fuzzy. This in turn seems to be based one of two ideas (I am not
> sure which)
> a. 'int' might either mean to some people 'some int associated with the
> f
On Jan 28, 2008 8:00 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
> I wish this thread could be truncated. It's got me going round and
> round. I'm completely floored, and will doubtless end up barking mad -
> you know, like a ceil.
Me too. All the arguments have been repeated over and over. It rea
Raymond Hettinger wrote:
> [Terry Reedy]
>> For one data point, I asked my bright 13-year-old for the 'integer part' of
>> 3.1, 3.9, -3.1, and -3.9 and got the expected 3,3,-3,-3 (as with int()).
>> But asking 'truncate' the same numbers or even 'truncate toward zero' got a
>> blank stare, which
[Terry Reedy]
> For one data point, I asked my bright 13-year-old for the 'integer part' of
> 3.1, 3.9, -3.1, and -3.9 and got the expected 3,3,-3,-3 (as with int()).
> But asking 'truncate' the same numbers or even 'truncate toward zero' got a
> blank stare, which did not surprise me too much a
> No, using trunc(x) makes it clear that the argument and return
> value are numbers. Using x.trunc() doesn't.
Not sure where this is notion comes from.
Terry Reedy's post provides a datapoint to the contrary.
Besides, there is no problem along these lines that
can't be cured by a better method n
As has occurred since the inception of PyCon, there will be a sprint
on the Python core at this year's conference!
If you will be attending PyCon (or will be in Chicago during the dates
of the sprints), attending the sprint is a great way to give back to
Python. Working on Python itself tends to d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 28, 2008, at 5:08 PM, Martin v. Löwis wrote:
> Would it help if I branch
> branches/release23-maint/Lib/email to branches/email-2.3 ?
> Or should I branch the entire release23-maint to email-2.3?
> (branches are cheap in subversion)
> (*)
I ju
Please ignore my last email. The idea for combining trunc, ceil,
floor, etc was probably just a distractor.
[GvR]
> One thing I'm beginning to feel more and more strongly about
> is that round, trunc, ceil and floor all belong in the same
> category, and either should all be builtins or should a
Raymond Hettinger wrote:
[snip..]
P.S. One place to attach the constants is to the function object, so
we would write:
x = round(3.1) # ROUND_TO_EVEN
x = round(3.1, round.CEIL)
. . .
Or Python could gain a first class enumeration structure, a type which has
proved usefu
> One thing I'm beginning to feel more and more strongly about
> is that round, trunc, ceil and floor all belong in the same
> category, and either should all be builtins or should all
> be in math.
>
> I should also admit that the 2-arg version of round() was
> borrowed from ABC, but the use ca
Jeroen Ruigrok van der Werven wrote:
> I cannot find anything explicitly in favour of or against this in POSIX. The
> stuff quoted below is what I could find.
>
> "3.105 Command Language Interpreter
>
> STDERR
>
> This section does not describe error messages that refer to incorrect
> operation
Guido van Rossum wrote:
> On Jan 28, 2008 12:35 AM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>>So it appears that the official Unix Way prefers using stderr
>>over stdout for prompting, if using the std files for it at all.
>
> That's a dangerous generalization from just one example. I'd prefer it
On Jan 28, 2008 2:28 PM, Daniel Stutzbach
<[EMAIL PROTECTED]> wrote:
> On Jan 28, 2008 4:00 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > No, using trunc(x) makes it clear that the argument and return value
> > are numbers. Using x.trunc() doesn't.
>
> How often do you expect someone to be lo
On Jan 28, 2008 4:00 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> No, using trunc(x) makes it clear that the argument and return value
> are numbers. Using x.trunc() doesn't.
How often do you expect someone to be looking at code where a trunc()
method is being called and the variable could pl
> The problem is that I make separate releases of the standalone email
> package from these branches, so that means that email 3.0.3 or 2.5.10
> will have regressions.
>
> Unless you're offering to also re-apply these changes after you make the
> Python releases .
If they are there primarily to
On Jan 28, 2008 1:54 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > This is why len() is not a method:
> >
> > map(len, list_of_strings)
>
> That's a good use case - but is that the reason?
>
> I would think that the true historical reason is that when len()
> was introduced, there weren'
[MvL]
> I wouldn't want to propose removal of len(), no. However,
> I do think that adding more builtins (trunc in particular)
> is bad, especially when they make perfect methods.
+1
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
On Jan 28, 2008, at 4:47 PM, Barry Warsaw wrote:
> The problem is that I make separate releases of the standalone email
> package from these branches, so that means that email 3.0.3 or 2.5.10
> will have regressions.
Releasing the email package from the Python maintenance branches is
probably i
> This is why len() is not a method:
>
> map(len, list_of_strings)
That's a good use case - but is that the reason?
I would think that the true historical reason is that when len()
was introduced, there weren't methods in the language. And even
when support for methods was added, many types
On Jan 28, 2008 1:47 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> >> If the intent is really to do a source-only releases mostly for system
> >> vendors, then I don't see the harm in leaving those changes in. I mean,
> >> a vendor is going to cherry pick the ones they wan
> While I couldn't locate such a document, it makes sense when you
> consider that if such a process is part of a pipeline you really don't
> want the prompts being handled as input by the downstream processes.
>
> That's why mv and similar utilities prompt on standard error.
No, that doesn't r
Martin v. Löwis wrote:
>> If the intent is really to do a source-only releases mostly for system
>> vendors, then I don't see the harm in leaving those changes in. I mean,
>> a vendor is going to cherry pick the ones they want anyway, so let's
>> just make it easy for them to do this. That might
> If the intent is really to do a source-only releases mostly for system
> vendors, then I don't see the harm in leaving those changes in. I mean,
> a vendor is going to cherry pick the ones they want anyway, so let's
> just make it easy for them to do this. That might mean publishing the
> svn l
-On [20080128 19:51], Jeroen Ruigrok van der Werven ([EMAIL PROTECTED]) wrote:
>I cannot find anything explicitly in favour of or against this in POSIX. The
>stuff quoted below is what I could find. I do not think there's a hard
>mandate either way, but from my experience of
On Jan 27, 2008 6:08 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > Ignoring whether this is the right thing to do, should this be in sys or
> in gc?
>
> Yeah, good idea. The gc module makes sense.
>
Does it? The gc module is specific to the cyclic-gc system. I don't se
Guido van Rossum wrote:
> I do think that another (final) 3.0 alpha before PyCon would also be a
> good idea. This way we can gel the release some more. For 2.6 I think
> we'll need more alpha releases after PyCon; I doubt the backporting
> from 3.0 (which has only started seriously quite recently)
On Jan 28, 2008 11:17 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
> > That's a dangerous generalization from just one example. I'd prefer it
> > if you could unearth some POSIX or Linux base document saying this.
> >
> While I couldn't locate such a document, it makes sense when you
> consider that
Guido van Rossum wrote:
> On Jan 28, 2008 12:35 AM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Isaac Morland wrote:
>>
>>> What about an option (maybe even a default) to send the prompt to stdin?
>>>
>>> The Postgres command line interface psql appears to do this:
>>>
>>> $ psql 2>&1 >/dev/null
>>> P
On Jan 28, 2008 10:50 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> What is the current thinking on this? Is the target still April 2008 as
> mentioned in PEP361? Are we going to have an alpha sometime soonish?
I would like to have an alpha before PyCon. It looks like there are
two release
What is the current thinking on this? Is the target still April 2008 as
mentioned in PEP361? Are we going to have an alpha sometime soonish?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
-On [20080128 18:57], Guido van Rossum ([EMAIL PROTECTED]) wrote:
>On Jan 28, 2008 12:35 AM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> So it appears that the official Unix Way prefers using stderr
>> over stdout for prompting, if using the std files for it at all.
On Jan 28, 2008 12:35 AM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Isaac Morland wrote:
>
> > What about an option (maybe even a default) to send the prompt to stdin?
> >
> > The Postgres command line interface psql appears to do this:
> >
> > $ psql 2>&1 >/dev/null
> > Password:
> > $
>
> No, it's
In article
<[EMAIL PROTECTED]>,
"Paul Moore" <[EMAIL PROTECTED]> wrote:
> 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
In article <[EMAIL PROTECTED]>,
"Martin v. Lowis" <[EMAIL PROTECTED]> wrote:
> > If the ambiguity is that 'int' behaviour is unspecified for floats - is
> > it naive to suggest we specify the behaviour?
>
> The concern is that whatever gets specified is arbitrary. There are many
> ways how an i
On Jan 27, 2008 5:11 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Jan 27, 2008, at 2:27 PM, Martin v. Löwis wrote:
>
> > Along with the release of 2.5.2, I would also like to release
> > new versions of 2.3 and 2.4. These will be security-only releases,
> > and include a few security-relevant b
On Sun, Jan 27, 2008 at 08:27:27PM +0100, "Martin v. Löwis" wrote:
> For 2.3, there are only few revisions that would be rolled back:
> r52798, r52803, r52824, r54342.
These changes can be reverted if you like; they were added for
Jython's sake, but it looks like they've now decided to skip direct
Jeroen Ruigrok van der Werven wrote:
> -On [20080128 03:13], Christian Heimes ([EMAIL PROTECTED]) wrote:
>> Do the int/float free lists cause any trouble or can they eat lots of
>> memory?
>
> I hope I am interpreting it correctly, but it seems
> http://evanjones.ca/memo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 27, 2008, at 2:27 PM, Martin v. Löwis wrote:
> Along with the release of 2.5.2, I would also like to release
> new versions of 2.3 and 2.4. These will be security-only releases,
> and include a few security-relevant bug fixes that are still bei
On 2008-01-27 08:14, Raymond Hettinger wrote:
>> . 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 i
-On [20080128 03:13], Christian Heimes ([EMAIL PROTECTED]) wrote:
>Do the int/float free lists cause any trouble or can they eat lots of
>memory?
I hope I am interpreting it correctly, but it seems
http://evanjones.ca/memoryallocator/ explanation on that still applies:
"The worst of
Isaac Morland wrote:
> What about an option (maybe even a default) to send the prompt to stdin?
>
> The Postgres command line interface psql appears to do this:
>
> $ psql 2>&1 >/dev/null
> Password:
> $
No, it's probably using the C stdlib routine getpass(). From the man
page:
The getpa
> On Jan 25, 2008 11:21 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>>... int() for making ints from the non-fractional
>>portion of a float.
To me, the concept of the "integer part of a float" isn't all that
well defined. It's really a property of a particular representation
rather than
44 matches
Mail list logo
