+1. Where do people want it, and what should its name be? I can
implement it if you like.
Another plausible output would be similar to frexp but with an integer
for the mantissa instead of a float. So:
A) math.frexp(3.2) == (0.80004, 2)
B) integral_frexp(3.2) == (3602879701896397, -5
> 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 int can be constructed from a float, so why is any such way
better than the others, and de
On Jan 24, 2008 3:32 PM, Michael Foord <[EMAIL PROTECTED]> wrote:
>
> Jeffrey Yasskin wrote:
> > On Jan 24, 2008 1:11 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >
> >> [Raymond Hettinger]
> >>
> >>> Since something similar is happening to math.ceil and math.floor,
> >>> I'm curious why trun
Raymond Hettinger wrote:
> [Raymond Hettinger]
>
>> Since something similar is happening to math.ceil and math.floor,
>> I'm curious why trunc() ended-up in builtins instead of the math
>> module. Doesn't it make sense to collect similar functions
>> with similar signatures in the same place?
>
Jeffrey Yasskin wrote:
> On Jan 24, 2008 1:11 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>> [Raymond Hettinger]
>>
>>> Since something similar is happening to math.ceil and math.floor,
>>> I'm curious why trunc() ended-up in builtins instead of the math
>>> module. Doesn't it make
On Jan 24, 2008 1:11 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Raymond Hettinger]
> > Since something similar is happening to math.ceil and math.floor,
> > I'm curious why trunc() ended-up in builtins instead of the math
> > module. Doesn't it make sense to collect similar functions
> >
On Jan 24, 2008 1:09 PM, Daniel Stutzbach
<[EMAIL PROTECTED]> wrote:
> On Jan 24, 2008 12:46 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > trunc() has well-defined semantics -- it takes a Real instance and
> > converts it to an Integer instance using round-towards-zero semantics.
> >
> > int(
rational.py contains code for turning a float into an
exact integer ratio. I've needed something like this in
other situations as well. The output is more convenient
than the mantissa/exponent pair returned by math.frexp().
I propose C-coding this function and either putting it in
the math modul
On Jan 24, 2008 12:40 PM, Eric Smith <[EMAIL PROTECTED]> wrote:
> The spreadsheet notes a possible __future__ statement requirement for
> oct(). The PEP doesn't mention this, and I'm not sure I understand the
> issue. Any clues?
You can't change the default oct() to return '0o123'; but perhaps y
[Raymond Hettinger]
> Since something similar is happening to math.ceil and math.floor,
> I'm curious why trunc() ended-up in builtins instead of the math
> module. Doesn't it make sense to collect similar functions
> with similar signatures in the same place?
[Christian Heimes]
> Traditionally t
On Jan 24, 2008 12:46 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> trunc() has well-defined semantics -- it takes a Real instance and
> converts it to an Integer instance using round-towards-zero semantics.
>
> int() has undefined semantics -- it takes any object and converts it
> to an int (a
Raymond Hettinger wrote:
> Since something similar is happening to math.ceil and math.floor,
> I'm curious why trunc() ended-up in builtins instead of the math
> module. Doesn't it make sense to collect similar functions
> with similar signatures in the same place?
Traditionally the math module i
Guido van Rossum wrote:
> On Jan 23, 2008 7:40 AM, Eric Smith <[EMAIL PROTECTED]> wrote:
>> In 3.0, the code to implement long.__format__() calls PyNumber_ToBase to
>> do the heavy lifting. If someone is planning on implementing
>> PyNumber_ToBase in 2.6, I'll wait for them to do so. If not, I gu
>> Can anyone explain to me why we need both trunc() and int()?
> trunc() has well-defined semantics -- it takes a Real instance
> and converts it to an Integer instance using round-towards-zero
> semantics.
Since something similar is happening to math.ceil and math.floor,
I'm curious why trunc()
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
>> It's entirely likely that the difference in what I am seeing and what
>> you guys are seeing is caused by my not having GNU readline
>> installed. Nevertheless, the behavior without it seems wrong, and is
>> certainl
IMO the actual behavior is incorrect.
On Jan 24, 2008 12:14 PM, Mike Kent <[EMAIL PROTECTED]> wrote:
> Guido van Rossum python.org> writes:
>
> >
> > > It's entirely likely that the difference in what I am seeing and what you
> > > guys
> > > are seeing is caused by my not having GNU readline ins
Guido van Rossum python.org> writes:
>
> > It's entirely likely that the difference in what I am seeing and what you
> > guys
> > are seeing is caused by my not having GNU readline installed. Nevertheless,
> > the behavior without it seems wrong, and is certainly different from the
> > documenta
On Jan 24, 2008 11:41 AM, Mike Kent <[EMAIL PROTECTED]> wrote:
> pobox.com> writes:
>
> >
> >
> > Isaac> Have people actually verified that the prompt is really sent to
> > Isaac> stderr right now by using 2>/dev/null to attempt to suppress it?
> >
> > Good point. On my machine at work (
On Jan 24, 2008 11:36 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > trunc() has well-defined semantics -- it takes a Real instance and
> > converts it to an Integer instance using round-towards-zero semantics.
>
> No. trunc calls __trunc__, which does whatever it pleases to do.
>
> >>> class
pobox.com> writes:
>
>
> Isaac> Have people actually verified that the prompt is really sent to
> Isaac> stderr right now by using 2>/dev/null to attempt to suppress it?
>
> Good point. On my machine at work (Solaris), Python 2.4 seems to send its
> raw_input prompt to stdout, not st
> trunc() has well-defined semantics -- it takes a Real instance and
> converts it to an Integer instance using round-towards-zero semantics.
No. trunc calls __trunc__, which does whatever it pleases to do.
>>> class A:
... def __trunc__(self):
... return 0
...
>>> a=A()
>>> trunc(a)
0
>
Beware: this may depend on whether GNU readline is enabled or not --
under many circumstances, raw_input() calls GNU readline instead of
using sys.stdin/stdout.
I do agree that if there are any conditions where it uses stderr
instead of stdout those are mistakes.
On Jan 24, 2008 9:47 AM, <[EMAIL
On Jan 24, 2008 10:36 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Can anyone explain to me why we need both trunc() and int()?
trunc() has well-defined semantics -- it takes a Real instance and
converts it to an Integer instance using round-towards-zero semantics.
int() has undefined seman
Can anyone explain to me why we need both trunc() and int()?
We used to be very resistant to adding new built-ins and
magic method protocols. In days not long past, this would
have encountered fierce opposition.
ISTM that numbers.py has taken on a life of its own and
is causing non-essential off
Isaac> Have people actually verified that the prompt is really sent to
Isaac> stderr right now by using 2>/dev/null to attempt to suppress it?
Good point. On my machine at work (Solaris), Python 2.4 seems to send its
raw_input prompt to stdout, not stderr:
% python
Python 2.4.2
On Thu, Jan 24, 2008 at 12:36:51PM -0500, 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:
> $
>
> (I typed my password and then I quit by typing
On Thu, 24 Jan 2008, [EMAIL PROTECTED] wrote:
>Mike> 2. Is this really the hard-coded behavior we want? I don't think
>Mike>my use-case is that odd; in fact, what I find very odd is that
>Mike>the prompt output is send to stderr. I mean, I'm printing the
>Mike>prompt
Mike> 2. Is this really the hard-coded behavior we want? I don't think
Mike>my use-case is that odd; in fact, what I find very odd is that
Mike>the prompt output is send to stderr. I mean, I'm printing the
Mike>prompt for a question, not some error message. Can there
I have created issue #1923 to keep track of this.
Stephen Emslie
On Jan 23, 2008 6:00 PM, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> could you put this on bugs.python.org and follow up with a reference to the
> issue # for better tracking?
>
>
>
> On 1/23/08, stephen emslie <[EMAIL PROTECTED]>
Recently I was trying to debug an old python program who's maintenance I
inherited. I was using the quick-and-dirty method of putting some 'print
>>sys.stderr' statements in the code, and then running the command with
'2>filename' appended to the end of the command line. Imagine my surprise
to se
> But on windows, ":" is special letter after drive letter. (ex:
> "C:/Winnt/foo/bar")
> So I imagine open() or something converts ":" to "!" (valid character as
> file name).
Sorry, I lied. :-(
open() didn't change ":", test_mailbox.py (TestMaildir.setUp) changed
self._box.colon to "!"
Otherwi
> From:
>
http://www.python.org/dev/buildbot/all/x86%20XP-4%202.5/builds/107/step-test/0
>
> The errors are:
>
> File
"E:\cygwin\home\db3l\buildarea\2.5.bolen-windows\build\lib\test\test_mailbox
.py",
> line 522, in test_consistent_factory
> msg2 = box.get_message(key)
> File
"E:\cygwin\hom
Neal Norwitz schrieb:
> We need to fix the Windows buildbots. 2 tests are currently failing
> for 2.5.2: test_mailbox test_winreg
The test_winreg failure is a funny one:
The py3k test_winreg fails because of a bug in the test itself; I fixed
this in rev. 60236. The failing test leaves a key in
Oh good. Reading the Modules/_struct.c code I see that is indeed what
happens. There are still several instances of misused struct pack and
unpack strings in Lib but the problem is less serious, I'll make a new patch
that just addresses those.
___
Pytho
Gregory P. Smith wrote:
>
> The documentation for the struct module says:
>
> http://docs.python.org/dev/library/struct.html#module-struct
>
> " short is 2 bytes; int and long are 4 bytes; long long ( __int64 on
> Windows) is 8 bytes"
>
> and lists 'l' and 'L' as the pack code for a C long.
We need to fix the Windows buildbots. 2 tests are currently failing
for 2.5.2: test_mailbox test_winreg
From:
http://www.python.org/dev/buildbot/all/x86%20XP-4%202.5/builds/107/step-test/0
The errors are:
File
"E:\cygwin\home\db3l\buildarea\2.5.bolen-windows\build\lib\test\test_mailbox.py
36 matches
Mail list logo
