New submission from Mark Summerfield:
When I start IDLE I get this:
Python 3.0a2 (r30a2:59382, Dec 10 2007, 14:21:37)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
Type copyright, credits or license() for more information.
Mark Summerfield added the comment:
Amaury Forgeot d'Arc says he's fixed this in change 59456 (but I don't
know how---or if---I can change its status).
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1585
__
Noam Raphael added the comment:
The Tcl code can be fonund here:
http://tcl.cvs.sourceforge.net/tcl/tcl/generic/tclStrToD.c?view=markup
What Tim says gives another reason for using that code - it means that
currently, the compilation of the same source code on two platforms can
result in a code
Christian Heimes added the comment:
Fixed in r59456
--
keywords: +py3k
nosy: +tiran
resolution: - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1585
__
Christian Heimes added the comment:
The problem is already fixed in svn. Can you download a svn checkout and
verify it that the code is working?
41848 skip.montanaro if (platform == 'darwin' and
--
nosy: +tiran
priority: - normal
resolution: - out of date
status: open -
Christian Heimes added the comment:
It's really a shame. It was a nice idea ...
Could we at least use the new formating for str(float) and the display
of floats? In Python 2.6 floats are not displayed with repr(). They seem
to use yet another hook.
repr(11./5)
'2.2'
11./5
2.2002
Changes by Christian Heimes:
--
assignee: - loewis
nosy: +loewis
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1754489
_
___
Python-bugs-list mailing list
New submission from Mark Summerfield:
When I do:
import sys; dir(sys)
everything is shown in plain black white, but in the IDLE that came
with Py30a1 color syntax highlighting is used.
--
components: IDLE
messages: 58423
nosy: mark
severity: minor
status: open
title: IDLE no
Noam Raphael added the comment:
I think that for str(), the current method is better - using the new
repr() method will make str(1.1*3) == '3.3003', instead of
'3.3'. (The repr is right - you can check, and 1.1*3 != 3.3. But for
str() purposes it's fine.)
But I actually think that
New submission from Christian Heimes:
The patch implements the instancemethod wrapper as discussed on the py3k
mailing list. The patch is roughly based on Marcin Kowalczyk patch but
it contains more fancy slots like repr, call etc. The rest is mostly
based on PyMethod_Type.
--
Andreas Hasenack added the comment:
The only difference between xmlrpclib.py from trunk and 2.5.1 is in the
Marshaller class. Unrelated, as far as I can see.
Note that it seems that the intent of the original code was to support
this x509-dict all along:
$ grep -n x509 xmlrpclib.py.trunk
1224:
Changes by Christian Heimes:
--
keywords: +py3k
priority: - normal
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1586
__
___
Python-bugs-list mailing list
Noam Raphael added the comment:
If I think about it some more, why not get rid of all the float
platform-dependencies and define how +inf, -inf and nan behave?
I think that it means:
* inf and -inf are legitimate floats just like any other float.
Perhaps there should be a builtin Inf, or at
New submission from Mark Summerfield:
x = complex(1, 2/3)
{0} {0:.5}.format(x)
'(1+0.6667j) (1+0.'
The complex number is being formatted as if it were a string and simply
truncated to 5 characters. I would expect each part of the complex
number to be formatted according to the format
Noam Raphael added the comment:
That's right, but the standard also defines that 0.0/0 - nan, and
1.0/0 - inf, but instead we raise an exception. It's just that in
Python, every object is expected to be equal to itself. Otherwise, how
can I check if a number is nan?
Christian Heimes added the comment:
Noam Raphael wrote:
* nan is an object of type float, which behaves like None, that is:
nan == nan is true, but nan nan and nan 3 will raise an
exception.
No, that's not correct. The standard defines that nan is always unequal
to nan.
False
float(inf)
Raghuram Devarakonda added the comment:
Since we already have os.rename, wouldn't it be better for shutil.move()
to be closer to command line 'mv'? I think Facundo's approach should work.
--
nosy: +draghuram
__
Tracker [EMAIL PROTECTED]
Christian Heimes added the comment:
I propose that we add three singletons to the float implementation:
PyFloat_NaN
PyFloat_Inf
PyFloat_NegInf
The singletons are returned from PyFloat_FromString() for nan, inf
and -inf. The other PyFloat_ method must return the singletons, too.
It's easy to
Guido van Rossum added the comment:
(1) Despite Tim's grave language, I don't think we'll need to write our
own correctly-rounding float input routine. We can just say that Python
won't work correctly unless your float input routine is rounding
correctly; a unittest should detect whether this
New submission from Andreas Hasenack:
(I hope I used the correct component for this report)
http://pypi.python.org/pypi/ssl/
I used the client example shown at
http://docs.python.org/dev/library/ssl.html#client-side-operation to
connect to a bank site called www.realsecureweb.com.br at
Andreas Hasenack added the comment:
Ups, typo in the script:
cert = verisign-inc-class-3-public-primary.pem
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1589
__
___
New submission from David Ripton:
Python 3.0a2, Gentoo Linux, x86
make altinstall installs idle, pydoc, and smtpd.py
This can partially break the previous Python install, which is counter
to the idea of altinstall being safe to use in parallel with an existing
install of a different version of
Christian Heimes added the comment:
Guido van Rossum wrote:
(1a) Perhaps it's better to only do this for Python 3.0, which has a
smaller set of platforms to support.
+1
Does Python depend on a working, valid and non-broken IEEE 754 floating
point arithmetic? Could we state the Python's float
Georg Brandl added the comment:
``'\0'`` will be correct.
--
nosy: +georg.brandl
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1583
__
___
Python-bugs-list mailing
Georg Brandl added the comment:
Crys: look closely at the diff, the 0 and is in the modified file.
--
nosy: +georg.brandl
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1584
__
Guido van Rossum added the comment:
Since we already have os.rename, wouldn't it be better for shutil.move()
to be closer to command line 'mv'? I think Facundo's approach should work.
I'd rather not do this. It might cause disasters for code that expects
the old semantics. If you want a way
Adam Olsen added the comment:
Thanks georg.
Added file: http://bugs.python.org/file8925/python2.6-set_wakeup_fd3.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1583
__Index: Doc/library/signal.rst
Guido van Rossum added the comment:
(1a) Perhaps it's better to only do this for Python 3.0, which has a
smaller set of platforms to support.
+1
Does Python depend on a working, valid and non-broken IEEE 754 floating
point arithmetic? Could we state the Python's float type depends on
Guido van Rossum added the comment:
Bill, can you respond?
--
assignee: - janssen
nosy: +gvanrossum, janssen
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1589
__
___
Raymond Hettinger added the comment:
Of course the latter isn't guaranteed to help for
non-IEEE-754 platforms -- some platforms don't have
NaNs at all!
ISTM, that years of toying with Infs and Nans has not
yielded a portable, workable solution. I'm concerned
that further efforts will
Guido van Rossum added the comment:
I'm tempted to call YAGNI on this.
--
nosy: +gvanrossum
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1587
__
___
Python-bugs-list
Guido van Rossum added the comment:
This really is a feature request -- in Python 2.x there is no formatting
code for complex numbers at all, and %.5s % complex(...) does the same
thing.
I agree it would be neat to have control over complex numbers using the
same formatting language used for
Guido van Rossum added the comment:
Maybe this would be a good GHOP task?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1588
__
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
[Raymond]
...
NaNs in particular are a really
difficult case because our equality testing routines
have a fast path where identity implies equality.
Works as intended in 2.5; this is Windows output:
1.#INF
nan = inf - inf
nan # really is a NaN
-1.#IND
nan
Tim Peters added the comment:
[Guido]
... We can just say that Python
won't work correctly unless your float input routine is rounding
correctly; a unittest should detect whether this is the case.
Sorry, but that's intractable. Correct rounding is a property that
needs to be proved, not
New submission from Erno Kuusela:
shelve objects set self.dict = 0 in their close() method. this
results in errors such as TypeError: unsubscriptable object and
AttributeError: 'int' object has no attribute 'has_key'.
This is fairly baffling for the user.
self.dict = 0 in close() is present in
Christian Heimes added the comment:
Guido van Rossum wrote:
No, traditionally Python has just used whatever C's double provides.
There are some places that benefit from IEEE 754, but few that require
it (dunno about optional extension modules).
I asked Thomas Wouter about IEEE 754:
I
Christian Heimes added the comment:
The wrapper is useful for C code which used PyMethod_New(func, NULL,
type) in 2.5. W/o a wrapper people may have to rewrite and redesign
their code base.
For example see http://bugs.python.org/issue1505 and r59215. I had to
rewrite a good bunch of code just
Guido van Rossum added the comment:
Do you know of any system that supports Python and floats but doesn't
have IEEE 753 semantics?
(Assuming you meant 754.)
I'm pretty sure the VAX doesn't have IEEE FP, and it used to run Unix
and Python. Ditto for Crays -- unsure if we still support that
Guido van Rossum added the comment:
Correct rounding is a property that needs to be proved, not tested.
I take it your position is that this can never be done 100% correctly so
it shouldn't go in? That's disappointing, because the stream of
complaints that round is broken won't stop (we had
Guido van Rossum added the comment:
OK, you've convinced me. Let's just make it a C API for now.
On Dec 11, 2007 10:56 AM, Christian Heimes [EMAIL PROTECTED] wrote:
Christian Heimes added the comment:
The wrapper is useful for C code which used PyMethod_New(func, NULL,
type) in 2.5. W/o a
New submission from Joseph Armbruster:
URL: http://svn.python.org/projects/python/branches/py3k
Revision: 59467
The spacing of the builtin_format function did not appear to be
consistent with the rest of the .c file.
See attached patch
--
components: Interpreter Core
files:
Kurt B. Kaiser added the comment:
r59468
Thanks for the update!
--
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1612746
_
___
Christian Heimes added the comment:
Applied in r59469
The PyInstanceMethod_Type is not exposed to Python programs.
--
resolution: - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1587
Christian Heimes added the comment:
Yes, 2.5 and 2.6 are affected, too. The scripts are install by setup.py
in sharedinstall.
--
nosy: +tiran
priority: - normal
versions: +Python 2.5, Python 2.6
__
Tracker [EMAIL PROTECTED]
New submission from Just van Rossum:
On intel, MacOS.GetCreatorAndType() returns the creator and type code with
the wrong endianness, eg. as 'DCBA' instead of 'ABCD'.
--
components: Macintosh
messages: 58464
nosy: jvr
priority: normal
severity: normal
status: open
title:
Christian Heimes added the comment:
Applied in r59470
Thanks for noticing the issue :)
--
keywords: +patch, py3k
nosy: +tiran
priority: - normal
resolution: - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1593
Tim Peters added the comment:
[Guido]
I take it your position is that this can never be done 100% correctly
No. David Gay's code is believed to be 100% correctly-rounded and is
also reasonably fast in most cases. I don't know of any other open
string-float code that achieves both ( expect
Guido van Rossum added the comment:
I'd be willing to require eval(repr(x)) == x only for platforms whose
float input routine is correctly rounding. That would make the current
patch acceptable I believe -- but I believe you think there's a better
way in that case too? What way is that?
Also,
New submission from Amaury Forgeot d'Arc:
In file ceval.h, the macro Py_LeaveRecursiveCall is defined like this:
#define Py_LeaveRecursiveCall() \
do{ if((--PyThreadState_GET()-recursion_depth)\
_Py_CheckRecursionLimit - 50); \
New submission from Alexandre Vassalotti:
I think Python 2.x should mimic, or improve on, the behavior of Py3k for
handling broken pipes. That is:
1. Don't print the message close failed: [Errno 32] Broken pipe,
from filemodule.c; since this is impossible to override from Python.
2. Check
Guido van Rossum added the comment:
I'll entertain a patch for 2.6.
For 2.5 I think this smells too much like a feature.
--
nosy: +gvanrossum
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1596
__
Martin v. Löwis added the comment:
I think you are right - that's a bug. As a consequence, overflowed would
be cleared less often than it is now, which in turn may cause a fatal
abort in case it fails to recover from a stack overflow (i.e. if it
consumes another 50 stack frames, instead of
Bill Janssen added the comment:
Unfortunately, hostname matching is one of those ideas that seemed
better when it was thought up than it actually proved to be in practice.
I've had extensive experience with this, and have found it to almost
always an application-specific decision. I thought
Noam Raphael added the comment:
If I understand correctly, there are two main concerns: speed and
portability. I think that they are both not that terrible.
How about this:
* For IEEE-754 hardware, we implement decimal/binary conversions, and
define the exact behaviour of floats.
* For
Guido van Rossum added the comment:
Sounds okay, except that I think that for some folks (e.g. numeric
Python users) I/O speed *does* matter, as their matrices are very
large, and their disks and networks are very fast.
__
Tracker [EMAIL PROTECTED]
Christian Heimes added the comment:
Updates:
* Some minor cleanups
* First draft of lazy modules implemented in C. It works but it needs
some cleanup and more error checking.
--
keywords: +patch
title: First draft of a post import hook - [Patch] Working post import hook
and lazy
New submission from Guido van Rossum:
In debug mode, on my Ubuntu Linux box, this fails on the last iteration:
$ ./python Lib/test/regrtest.py -R:20 test_ctypes
test_ctypes
beginning 25 repetitions
1234567890123456789012345
test test_ctypes failed -- Traceback (most
Noam Raphael added the comment:
If I were in that situation I would prefer to store the binary
representation. But if someone really needs to store decimal floats,
we can add a method fast_repr which always calculates 17 decimal
digits.
Decimal to binary conversion, in any case, shouldn't be
Guido van Rossum added the comment:
If I were in that situation I would prefer to store the binary
representation. But if someone really needs to store decimal floats,
we can add a method fast_repr which always calculates 17 decimal
digits.
They can just use %.17g % x
Decimal to binary
Guido van Rossum added the comment:
I've tracked my problem to the GCC optimizer. The default optimizer
setting is -O3. When I edit the Makefile to change this to -O1 or -O0
and recompile (only) doubledigits.c, repr(1e5) starts returning
'10.0' again. -O2 behaves the same as -O3.
Now, don't
Kurt B. Kaiser added the comment:
This is very useful!
However, it isn't fully baked. Please test more
before submitting patches. Try to break them on
corner cases.
import CallTips
CallTips.CallTips(
AttributeError: 'NoneType' object has no attribute
'splitlines'
def foo():
pass
foo(
New submission from Scott Moser:
I'm running into a problem with imaplib where it is unable to download a
message. The example code at
http://www.python.org/doc/current/lib/imap4-example.html easily
demonstrates the problem.
#!/usr/bin/python
import getpass, imaplib
M =
Changes by Pooja:
--
components: IDLE
nosy: Pooja
severity: normal
status: open
title: IDLE hangs if os.spwanv command is given
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1599
__
Mark Summerfield added the comment:
On 2007-12-11, Guido van Rossum wrote:
Guido van Rossum added the comment:
This really is a feature request -- in Python 2.x there is no formatting
code for complex numbers at all, and %.5s % complex(...) does the same
thing.
I thought Python 3 was meant
65 matches
Mail list logo
