[ python-Bugs-1083793 ] Python 2.4 crashes
Bugs item #1083793, was opened at 2004-12-12 10:25
Message generated for change (Comment added) made by axel_kaiser
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Axel Kaiser (axel_kaiser)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4 crashes
Initial Comment:
The new Python 2.4 crashes when starting some of my
programs. This happens under win xp as well as under
win nt. The crashes are reproduceble, but I didn't
succeed in finding the exact place where it happens.
In the attachment you find a Dr. Watson logfile. I hope
it helps. Otherwise I think I will be able to help with
more information.
Thanks in advance
Axel Kaiser
Germany
--
>Comment By: Axel Kaiser (axel_kaiser)
Date: 2004-12-17 13:12
Message:
Logged In: YES
user_id=1176563
That's it!!! I applied the patch to codecs.py and now it works
without crash!
Thanks a lot!
Let's close this thread.
--
Comment By: Walter Dörwald (doerwalter)
Date: 2004-12-16 15:34
Message:
Logged In: YES
user_id=89016
This sounds like it might be related to bug
http://www.python.org/sf/1076985. Can you retry your
scripts with the patch from
http://www.python.org/sf/1076985? What happens if you
replace the "cp1252" in the encoding header with "iso-8859-
1"?
A quick workaround might be to wrap the long source lines in
Sterbetafeln.py.
--
Comment By: Axel Kaiser (axel_kaiser)
Date: 2004-12-16 14:56
Message:
Logged In: YES
user_id=1176563
Okay, I finally was able to produce a small example. When I
start python from the commandline with
file "Lebenserwartung.py" python crashes. It doesn't crash
when I remove the coding-line (1st line) of
file "Sterbetafeln.py".
(The example can't run properly due to missing files, but
these don't influence the crashes)
Best regards, Axel
--
Comment By: Martin v. Löwis (loewis)
Date: 2004-12-15 23:39
Message:
Logged In: YES
user_id=21627
Can you create a small test case that demonstrates the problem?
--
Comment By: Axel Kaiser (axel_kaiser)
Date: 2004-12-15 21:58
Message:
Logged In: YES
user_id=1176563
Sorry, the attachment was not appended. By the way, the
problem occurs without any external modules/libraries. It
just juses python-source. The problem might be connected
with the use of module array.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-15 19:02
Message:
Logged In: YES
user_id=80475
Any objections to marking this as Invalid and closing the bug?
--
Comment By: Wolfgang Langner (tds33)
Date: 2004-12-15 16:16
Message:
Logged In: YES
user_id=600792
The FILE pointer is specific to your c-lib.
Different versions of the ms c-lib have incompatible
implementations of this structure.
To work arround such problems use python to get the right FILE*
Example (not tested):
/* use pythons std c library to produce a FILE object
to avoid mess with different c libs in debug or release mode
and different versions used to compile python
*/
PyObject* pyFile = PyFile_FromString(fileName, "r");
FILE* const file = PyFile_AsFile(pyFile);
assert(0 != file);
const int succ = PyRun_SimpleFile(file, fileName);
// now remove py file object
Py_XDECREF(pyFile);
--
Comment By: salyee (salyee)
Date: 2004-12-15 07:17
Message:
Logged In: YES
user_id=1178573
I have the same or similar problem.
While python24.dll(Python 2.4 for Windows) uses msvcr71.dll
for CRT, host C++ program embeding Python 2.4 as a script
engine, in my project, is compiled by VC++ 6.0 (msvcrt.dll).
So, the following code snip makes a crash.
FILE* fp = fopen("somecode.py", "rt"); // uses msvcrt.dll
PyRun_SimpleFile(fp, "somecode.py); // uses msvcr71.dll
inside. Cause of a crash.
In my case, I must use VC++ 6.0 and I want clients of my
program to install Python 2.4 from www.python.org.
How do I solve this problem ?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-12 10:56
Message:
Logged In: YES
user_id=80475
The attachment didn't make it.
Be sure to check the upload box or it won't make it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470
[ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash
Bugs item #1076985, was opened at 2004-12-01 19:51
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Sebastian Hartte (dark-storm)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Incorrect behaviour of StreamReader.readline leads to crash
Initial Comment:
StreamReader.readline in codecs.py misinterprets the
size parameter. (File: codecs.py, Line: 296).
The reported crash happens if a file processed by the
python tokenizer is using a not built-in codec for
source file encoding (i.e. iso-8859-15) and has lines
that are longer than the define BUFSIZ in stdio.h on
the platform python is compiled on. (On Windows for
MSVC++ this define is 512, thus a line that is longer
than 511 characters should suffice to crash python with
the correct encoding).
The crash happens because the python core assumes that
the StreamReader.readline method returns a string
shorter than the platforms BUFSIZ macro (512 for MSVC).
The current StreamReader.readline() looks like this:
---
def readline(self, size=None, keepends=True):
""" Read one line from the input stream and
return the
decoded data.
size, if given, is passed as size argument
to the
read() method.
"""
if size is None:
size = 10
line = u""
while True:
data = self.read(size)
line += data
pos = line.find("\n")
if pos>=0:
self.charbuffer = line[pos+1:] +
self.charbuffer
if keepends:
line = line[:pos+1]
else:
line = line[:pos]
return line
elif not data:
return line
if size<8000:
size *= 2
---
However, the core expects readline() to return at most
a string of the length size. readline() instead passes
size to the read() function.
There are multiple ways of solving this issue.
a) Make the core reallocate the token memory if the
string returned by the readline function exceeds the
expected size (risky if the line is very long).
b) Fix, rename, remodel, change StreamReader.readline.
If no other part of the core or code expects size to do
nothing useful, the following readline() function does
behave correctly with arbitrarily long lines:
---
def readline(self, size=None, keepends=True):
""" Read one line from the input stream and
return the
decoded data.
size, if given, is passed as size argument
to the
read() method.
"""
if size is None:
size = 10
data = self.read(size)
pos = data.find("\n")
if pos>=0:
self.charbuffer = data[pos+1:] +
self.charbuffer
if keepends:
data = data[:pos+1]
else:
data = data[:pos]
return data
else:
return data # Return the data directly
since otherwise
# we would exceed the given size.
---
Reproducing this bug:
This bug can only be reproduced if your platform does
use a small BUFSIZ for stdio operations (i.e. MSVC), i
didn't check but Linux might use more than 8000 byte
for the default buffer size. That means you would have
to use a line with more than 8000 characters to
reproduce this.
In addition, this bug only shows if the python
libraries StreamReader.readline() method is used, if
internal codecs like Latin-1 are used, there is no
crash since the method isn't used.
I've attached a file that crashes my Python 2.4 on
Windows using the official binary released on
python.org today.
Last but not least here is the assertion that is broken
if python is compiled in debug mode with MSVC++ 7.1:
Assertion failed: strlen(str) < (size_t)size, file
\Python-2.4\Parser\tokenizer.
c, line 367
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-17 13:59
Message:
Logged In: YES
user_id=38388
Walter, the fix to .read() looks OK, but the implementation
of .readline() is not correct: there are far more line break
characters in Unicode than just \n. The correct way to check
would be by using .splitlines() which does know about all
the possible line break characters in Unicode, plus it also
handles line ends such as \r\n and just \r correctly. If
.splitlines() returns a list with more than one entry you
know that you've hit a line end and you can push the
remaining entries entries back onto the .charbuffer.
Another nit: you should bump the default for readsize to 72
- the average line size used in t
[ python-Bugs-1086603 ] segfault in readline
Bugs item #1086603, was opened at 2004-12-16 18:02 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in readline Initial Comment: It's possible to produce segfaults using two functions from the readline module by giving them negative values (GNU readline 4.3-10), at least in some circumstances. Python 2.5a0 (#10, Dec 15 2004, 19:53:33) [GCC 3.3.3 (Debian 20040401)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import readline [25290 refs] >>> readline.remove_history_item(-1) Segmentation fault >>> readline.replace_history_item(-1,'abc') Segmentation fault gdb reveals it happens because the (external) remove_history and replace_history_entry don't return NULL in these cases. I'm not sure whether we're responsible for checking the sanity of inputs or the GNU code should be returning NULL and isn't, but at least sometimes it doesn't. -- >Comment By: Michael Hudson (mwh) Date: 2004-12-17 14:18 Message: Logged In: YES user_id=6656 Hmm. I can't reproduce this (also with readline 4.3). Odd. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash
Bugs item #1076985, was opened at 2004-12-01 19:51
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Sebastian Hartte (dark-storm)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Incorrect behaviour of StreamReader.readline leads to crash
Initial Comment:
StreamReader.readline in codecs.py misinterprets the
size parameter. (File: codecs.py, Line: 296).
The reported crash happens if a file processed by the
python tokenizer is using a not built-in codec for
source file encoding (i.e. iso-8859-15) and has lines
that are longer than the define BUFSIZ in stdio.h on
the platform python is compiled on. (On Windows for
MSVC++ this define is 512, thus a line that is longer
than 511 characters should suffice to crash python with
the correct encoding).
The crash happens because the python core assumes that
the StreamReader.readline method returns a string
shorter than the platforms BUFSIZ macro (512 for MSVC).
The current StreamReader.readline() looks like this:
---
def readline(self, size=None, keepends=True):
""" Read one line from the input stream and
return the
decoded data.
size, if given, is passed as size argument
to the
read() method.
"""
if size is None:
size = 10
line = u""
while True:
data = self.read(size)
line += data
pos = line.find("\n")
if pos>=0:
self.charbuffer = line[pos+1:] +
self.charbuffer
if keepends:
line = line[:pos+1]
else:
line = line[:pos]
return line
elif not data:
return line
if size<8000:
size *= 2
---
However, the core expects readline() to return at most
a string of the length size. readline() instead passes
size to the read() function.
There are multiple ways of solving this issue.
a) Make the core reallocate the token memory if the
string returned by the readline function exceeds the
expected size (risky if the line is very long).
b) Fix, rename, remodel, change StreamReader.readline.
If no other part of the core or code expects size to do
nothing useful, the following readline() function does
behave correctly with arbitrarily long lines:
---
def readline(self, size=None, keepends=True):
""" Read one line from the input stream and
return the
decoded data.
size, if given, is passed as size argument
to the
read() method.
"""
if size is None:
size = 10
data = self.read(size)
pos = data.find("\n")
if pos>=0:
self.charbuffer = data[pos+1:] +
self.charbuffer
if keepends:
data = data[:pos+1]
else:
data = data[:pos]
return data
else:
return data # Return the data directly
since otherwise
# we would exceed the given size.
---
Reproducing this bug:
This bug can only be reproduced if your platform does
use a small BUFSIZ for stdio operations (i.e. MSVC), i
didn't check but Linux might use more than 8000 byte
for the default buffer size. That means you would have
to use a line with more than 8000 characters to
reproduce this.
In addition, this bug only shows if the python
libraries StreamReader.readline() method is used, if
internal codecs like Latin-1 are used, there is no
crash since the method isn't used.
I've attached a file that crashes my Python 2.4 on
Windows using the official binary released on
python.org today.
Last but not least here is the assertion that is broken
if python is compiled in debug mode with MSVC++ 7.1:
Assertion failed: strlen(str) < (size_t)size, file
\Python-2.4\Parser\tokenizer.
c, line 367
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2004-12-17 19:12
Message:
Logged In: YES
user_id=89016
Here is a second version of the patch
(fix_readline_and_read2.diff) that implements all those
changes. With this we get "universal newline" support for
free. Note that there is still one corner case: If the byte
stream is temporarily exhausted and the last character read is
a \r, and the next character read (once the stream contains
new data) is an \n, this will result in two lines instead of one.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-17 13:59
Message:
Logged In: YES
user_id=38388
Walter, the fix to .read() l
[ python-Bugs-1087216 ] datetime module documentation missing critical detail
Bugs item #1087216, was opened at 2004-12-17 13:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: datetime module documentation missing critical detail Initial Comment: The datetime documentation - both pydoc and the manual - fail to specify the arguments used to create a date/time/datetime object. The manual implies that for date it's date(year, month, day), but that's about it. It would be nice if both could be extended to include examples. For date, say: datetime.date(2004, 12, 25) - create a date object for christmas, 2004. I can't give examples for time and datetime, because I'm not sure what the format is. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1087216 ] datetime module documentation missing critical detail
Bugs item #1087216, was opened at 2004-12-17 14:22 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: datetime module documentation missing critical detail Initial Comment: The datetime documentation - both pydoc and the manual - fail to specify the arguments used to create a date/time/datetime object. The manual implies that for date it's date(year, month, day), but that's about it. It would be nice if both could be extended to include examples. For date, say: datetime.date(2004, 12, 25) - create a date object for christmas, 2004. I can't give examples for time and datetime, because I'm not sure what the format is. -- >Comment By: Tim Peters (tim_one) Date: 2004-12-17 14:56 Message: Logged In: YES user_id=31435 I'm not sure which docs you're looking at. I'm looking at the Python docs , like here: http://docs.python.org/lib/datetime-date.html That seems very clear to me: """ class date(year, month, day) All arguments are required. Arguments may be ints or longs, in the following ranges: MINYEAR <= year <= MAXYEAR 1 <= month <= 12 1 <= day <= number of days in the given month and year If an argument outside those ranges is given, ValueError is raised. """ There are equally precise docs for all the datetime.* classes. For example, you mentioned time: """ class time(hour[, minute[, second[, microsecond[, tzinfo) All arguments are optional. tzinfo may be None, or an instance of a tzinfo subclass. The remaining arguments may be ints or longs, in the following ranges: 0 <= hour < 24 0 <= minute < 60 0 <= second < 60 0 <= microsecond < 100. If an argument outside those ranges is given, ValueError is raised. All default to 0 except tzinfo, which defaults to None. """ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1087216 ] datetime module documentation missing critical detail
Bugs item #1087216, was opened at 2004-12-17 13:22 Message generated for change (Comment added) made by mwm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: datetime module documentation missing critical detail Initial Comment: The datetime documentation - both pydoc and the manual - fail to specify the arguments used to create a date/time/datetime object. The manual implies that for date it's date(year, month, day), but that's about it. It would be nice if both could be extended to include examples. For date, say: datetime.date(2004, 12, 25) - create a date object for christmas, 2004. I can't give examples for time and datetime, because I'm not sure what the format is. -- >Comment By: Mike Meyer (mwm) Date: 2004-12-17 14:23 Message: Logged In: YES user_id=93910 You're right - I was just blind when reading the module documenation. It would still be nice if I could get that information from pydoc/help, though. -- Comment By: Tim Peters (tim_one) Date: 2004-12-17 13:56 Message: Logged In: YES user_id=31435 I'm not sure which docs you're looking at. I'm looking at the Python docs , like here: http://docs.python.org/lib/datetime-date.html That seems very clear to me: """ class date(year, month, day) All arguments are required. Arguments may be ints or longs, in the following ranges: MINYEAR <= year <= MAXYEAR 1 <= month <= 12 1 <= day <= number of days in the given month and year If an argument outside those ranges is given, ValueError is raised. """ There are equally precise docs for all the datetime.* classes. For example, you mentioned time: """ class time(hour[, minute[, second[, microsecond[, tzinfo) All arguments are optional. tzinfo may be None, or an instance of a tzinfo subclass. The remaining arguments may be ints or longs, in the following ranges: 0 <= hour < 24 0 <= minute < 60 0 <= second < 60 0 <= microsecond < 100. If an argument outside those ranges is given, ValueError is raised. All default to 0 except tzinfo, which defaults to None. """ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1084279 ] status of small floats in xml-rpc ?
Bugs item #1084279, was opened at 2004-12-13 05:07
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Nobody/Anonymous (nobody)
Summary: status of small floats in xml-rpc ?
Initial Comment:
Hi,
I've been reading through the xmlrpclib.py code to see
that floats are marshalled the following way:
def dump_double(self, value, write):
write("")
write(repr(value))
write("\n")
dispatch[FloatType] = dump_double
Using repr() means that small or big floats, for
example, will be output using the exponent notation:
>>> repr(2**-15)
'3.0517578125e-05'
Unfortunately, the XML-RPC specification does not allow
this notation:
"At this time, only decimal point notation is allowed,
a plus or a minus, followed by any number of numeric
characters, followed by a period and any number of
numeric characters. Whitespace is not allowed. The
range of allowable values is implementation-dependent,
is not specified."
(http://www.xmlrpc.com/spec)
Thus floats marshalled using xmlrpclib may not be
readable using other XML-RPC implementations.
(I don't have any concrete data about this though)
--
>Comment By: Tim Peters (tim_one)
Date: 2004-12-17 15:30
Message:
Logged In: YES
user_id=31435
FWIW, I'd leave this alone. The XML-RPC spec is braindead
when it comes to floats, and any implementation that didn't
accept scientific notation would have to go out of its way to
cripple the facilities all languages with a string->double
function supply.
Raymond, under any IEEE-conforming string->double
implementation, eval(repr(x))==x will hold provided that repr
(x) be roughly correct to at least 17 significant decimal digits,
and that x is finite. It doesn't matter whether the string uses
exponent notation. OTOH, IIRC Python got in trouble once
with some old Solaris string->double C routine that went
insane if the string had "too many" characters. Indeed,
making bad assumptions about maximum string length seems
a lot more likely to me than that someone has a string-
>double routine that can't deal with exponents.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-16 05:32
Message:
Logged In: YES
user_id=80475
After more thought, I'm concerned that switching to full
decimal notation will break the guarantee eval(repr(x))==x.
Also, Skip's thoughts seem reasonable. Rather than
switching to a non-compact format, it may be best to way for
the spec to catchup with real implementations.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 17:19
Message:
Logged In: YES
user_id=80475
Various slightly unsatisfactory answers:
* It started out that way because that's what C did.
* It stayed that way because no one has requested it
* It may be that outside of XMLRPC there are very few valid
use cases.
* Future needs can be met by the decimal module.
--
Comment By: Antoine Pitrou (pitrou)
Date: 2004-12-13 14:04
Message:
Logged In: YES
user_id=133955
I'm gonna ask a stupid question (I'm quite a beginner in
Python). Why isn't there a %f-life formatting code for doing
just what you wrote - printing the float in full precision
in non-exponent format ?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 13:12
Message:
Logged In: YES
user_id=80475
The thought was "be liberal in what you accept and be strict
on was is emitted." Still, the question is valid.
For C, it looks like strtod() is at the root of everything
converting from floats. The spec lays no limits on the
input format (exponents vs full decimal representation).
Instead, it just checks that the result is inside the range
of representable values and did not underflow.
Some experiments with MSC6 confirm that the full range may
be entered as regular decimals. Experiments with Perl show
the same result. I suspect all TCL and Ruby also have
strtod() at the core.
--
Comment By: Skip Montanaro (montanaro)
Date: 2004-12-13 10:38
Message:
Logged In: YES
user_id=44345
I understand what you''re doing, but I wonder if in the
process interoperability with other XML-RPC implementations
might actually get worse. While the spec doesn't support
exponential notation, most programming languages do, and
probably happily accept "1.234e-147" as a floating point
input. Python seems not to have problems accepting floating
point inputs with huge n
[ python-Bugs-518846 ] exception cannot be new-style class
Bugs item #518846, was opened at 2002-02-17 12:09 Message generated for change (Comment added) made by robey1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Magnus Heino (magnusheino) Assigned to: Guido van Rossum (gvanrossum) Summary: exception cannot be new-style class Initial Comment: [EMAIL PROTECTED] magnus]$ python2.2 Python 2.2 (#1, Jan 26 2002, 14:27:24) [GCC 2.96 2731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class foo(object): ... pass ... >>> raise foo() Traceback (most recent call last): File "", line 1, in ? TypeError: exceptions must be strings, classes, or instances, not foo >>> -- Comment By: Robey Pointer (robey1) Date: 2004-12-17 12:46 Message: Logged In: YES user_id=1179122 (I wish we could do this in email instead of cluttering up an already-messy bug...) Forget about throwing non-Exception-based objects: it's a red herring. The bug to focus on is the title: "exception cannot be new-style class". Bottom line: This subclass of Exception can not be raised in python 2.3: class MyException (Exception, object): pass pje's comment below from (2002-07-11 13:12) is a nice summary of how to solve it. -- Comment By: Martin v. Löwis (loewis) Date: 2004-12-16 05:00 Message: Logged In: YES user_id=21627 This statement, as literally made, is incorrect: >>> class X(Exception): ... pass ... >>> e=X() >>> type(e) >>> raise e Traceback (most recent call last): File "", line 1, in ? __main__.X: <__main__.X instance at 0x401f2b4c> In this example, type(e) works, and x is an object which has Exception among its base classes. Still, I can throw x, despite your claim that I cannot. Even if I interpret your statement more literally (i.e. that you are talking about objects for which type(e) is a new-style class): Why do you think this statement explains there is a bug? As for why it is a new feature: it currently doesn't work, and anybody trying it will quickly find out that it doesn't work. The language reference says it doesn't work. The TypeError you get says it doesn't work. So that it doesn't work is clearly intentional; changing it will be a new feature. Notice that it is very difficult to implement this feature, as something needs to happen with strings and subtypes of str. Currently, string exceptions are caught by identity. If arbitrary objects can be used as exceptions, then strings should also be caught by type, not by identity; this is a backwards-incompatible change. A clean solution would be to deprecate string exceptions in 2.5, completely ban them in 2.6, and allow arbitrary objects to act as exceptions in 2.7. Please do read the entire thread of this RFE. -- Comment By: Robey Pointer (robey1) Date: 2004-12-15 15:39 Message: Logged In: YES user_id=1179122 Let me try to rephrase the problem so that it's obvious that this is a bug, and not a feature: 'type(e)' on an exception will not work in 2.3, and cannot be made to work from within python code. There's no way to throw an exception (ie an object with Exception in its ancestor list) that 'type(e)' will work on. :( -- Comment By: Martin v. Löwis (loewis) Date: 2004-12-15 13:59 Message: Logged In: YES user_id=21627 Whatever the solution to this problem, it is for sure that 2.4.x won't see it, because it will be a new feature. -- Comment By: Robey Pointer (robey1) Date: 2004-12-15 13:08 Message: Logged In: YES user_id=1179122 This caused me an hour of debugging a few nights ago. When using unified types, it's very confusing to find that not only does Exception not follow new-style object semantics, but it *can't*. Doing the obvious hack: class MyException (Exception, object): pass does not work! The interpreter (2.3) refuses to let you raise a unified-type object. And if you subclass exclusively from Exception, type(obj) returns 'instance' instead of the class (due to being an old-style object). Please fix this for 2.4! -- Comment By: Facundo Batista (facundobatista) Date: 2004-11-24 18:05 Message: Logged In: YES user_id=752496 Reproduced the bug in Py2.3. I think that this is a bug, at least because we "encourage" users to derive exceptions from Exception, so they should be able to not do it. The moment we say that they "must" derive from Exception, this can be closed (of course, this is my *very* personal opinion, ;) ---
[ python-Bugs-1087216 ] datetime module documentation missing critical detail
Bugs item #1087216, was opened at 2004-12-17 13:22 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: datetime module documentation missing critical detail Initial Comment: The datetime documentation - both pydoc and the manual - fail to specify the arguments used to create a date/time/datetime object. The manual implies that for date it's date(year, month, day), but that's about it. It would be nice if both could be extended to include examples. For date, say: datetime.date(2004, 12, 25) - create a date object for christmas, 2004. I can't give examples for time and datetime, because I'm not sure what the format is. -- >Comment By: Skip Montanaro (montanaro) Date: 2004-12-17 15:05 Message: Logged In: YES user_id=44345 Pydoc generates documentation based upon what it finds in docstrings and function signatures. It can't get at the signatures of functions written in C. In Python 2.4 pydoc generates a link to a local or online version of the docs for the subject module: NAME datetime - Fast implementation of the datetime type. FILE /Users/skip/local/lib/python2.5/lib-dynload/datetime.so MODULE DOCS http://www.python.org/doc/current/lib/module-datetime.html CLASSES __builtin__.object date datetime ... I think that's the best that can be done short of macroizing the hell out of C extension modules to allow function signatures to be captured as attributes attached to the functions, similar to what GNU Emacs did many years ago. Correct me if I'm wrong, but I don't think we want to go down that path (take a peek at the Emacs source if you are in doubt). -- Comment By: Mike Meyer (mwm) Date: 2004-12-17 14:23 Message: Logged In: YES user_id=93910 You're right - I was just blind when reading the module documenation. It would still be nice if I could get that information from pydoc/help, though. -- Comment By: Tim Peters (tim_one) Date: 2004-12-17 13:56 Message: Logged In: YES user_id=31435 I'm not sure which docs you're looking at. I'm looking at the Python docs , like here: http://docs.python.org/lib/datetime-date.html That seems very clear to me: """ class date(year, month, day) All arguments are required. Arguments may be ints or longs, in the following ranges: MINYEAR <= year <= MAXYEAR 1 <= month <= 12 1 <= day <= number of days in the given month and year If an argument outside those ranges is given, ValueError is raised. """ There are equally precise docs for all the datetime.* classes. For example, you mentioned time: """ class time(hour[, minute[, second[, microsecond[, tzinfo) All arguments are optional. tzinfo may be None, or an instance of a tzinfo subclass. The remaining arguments may be ints or longs, in the following ranges: 0 <= hour < 24 0 <= minute < 60 0 <= second < 60 0 <= microsecond < 100. If an argument outside those ranges is given, ValueError is raised. All default to 0 except tzinfo, which defaults to None. """ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash
Bugs item #1076985, was opened at 2004-12-01 19:51
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Sebastian Hartte (dark-storm)
>Assigned to: Walter Dörwald (doerwalter)
Summary: Incorrect behaviour of StreamReader.readline leads to crash
Initial Comment:
StreamReader.readline in codecs.py misinterprets the
size parameter. (File: codecs.py, Line: 296).
The reported crash happens if a file processed by the
python tokenizer is using a not built-in codec for
source file encoding (i.e. iso-8859-15) and has lines
that are longer than the define BUFSIZ in stdio.h on
the platform python is compiled on. (On Windows for
MSVC++ this define is 512, thus a line that is longer
than 511 characters should suffice to crash python with
the correct encoding).
The crash happens because the python core assumes that
the StreamReader.readline method returns a string
shorter than the platforms BUFSIZ macro (512 for MSVC).
The current StreamReader.readline() looks like this:
---
def readline(self, size=None, keepends=True):
""" Read one line from the input stream and
return the
decoded data.
size, if given, is passed as size argument
to the
read() method.
"""
if size is None:
size = 10
line = u""
while True:
data = self.read(size)
line += data
pos = line.find("\n")
if pos>=0:
self.charbuffer = line[pos+1:] +
self.charbuffer
if keepends:
line = line[:pos+1]
else:
line = line[:pos]
return line
elif not data:
return line
if size<8000:
size *= 2
---
However, the core expects readline() to return at most
a string of the length size. readline() instead passes
size to the read() function.
There are multiple ways of solving this issue.
a) Make the core reallocate the token memory if the
string returned by the readline function exceeds the
expected size (risky if the line is very long).
b) Fix, rename, remodel, change StreamReader.readline.
If no other part of the core or code expects size to do
nothing useful, the following readline() function does
behave correctly with arbitrarily long lines:
---
def readline(self, size=None, keepends=True):
""" Read one line from the input stream and
return the
decoded data.
size, if given, is passed as size argument
to the
read() method.
"""
if size is None:
size = 10
data = self.read(size)
pos = data.find("\n")
if pos>=0:
self.charbuffer = data[pos+1:] +
self.charbuffer
if keepends:
data = data[:pos+1]
else:
data = data[:pos]
return data
else:
return data # Return the data directly
since otherwise
# we would exceed the given size.
---
Reproducing this bug:
This bug can only be reproduced if your platform does
use a small BUFSIZ for stdio operations (i.e. MSVC), i
didn't check but Linux might use more than 8000 byte
for the default buffer size. That means you would have
to use a line with more than 8000 characters to
reproduce this.
In addition, this bug only shows if the python
libraries StreamReader.readline() method is used, if
internal codecs like Latin-1 are used, there is no
crash since the method isn't used.
I've attached a file that crashes my Python 2.4 on
Windows using the official binary released on
python.org today.
Last but not least here is the assertion that is broken
if python is compiled in debug mode with MSVC++ 7.1:
Assertion failed: strlen(str) < (size_t)size, file
\Python-2.4\Parser\tokenizer.
c, line 367
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-17 22:19
Message:
Logged In: YES
user_id=38388
Looks good, please check it in with one correction:
"".join() should be u"".join().
Thanks, Walter !
--
Comment By: Walter Dörwald (doerwalter)
Date: 2004-12-17 19:12
Message:
Logged In: YES
user_id=89016
Here is a second version of the patch
(fix_readline_and_read2.diff) that implements all those
changes. With this we get "universal newline" support for
free. Note that there is still one corner case: If the byte
stream is temporarily exhausted and the last character read is
a \r, and the next character read (once the stream
[ python-Bugs-1087216 ] datetime module documentation missing critical detail
Bugs item #1087216, was opened at 2004-12-17 14:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: datetime module documentation missing critical detail Initial Comment: The datetime documentation - both pydoc and the manual - fail to specify the arguments used to create a date/time/datetime object. The manual implies that for date it's date(year, month, day), but that's about it. It would be nice if both could be extended to include examples. For date, say: datetime.date(2004, 12, 25) - create a date object for christmas, 2004. I can't give examples for time and datetime, because I'm not sure what the format is. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-17 17:28 Message: Logged In: YES user_id=80475 It looks like the docstrings could be a bit more informative: >>> print datetime.date.__doc__ Basic date type. Compare that with: >>> print collections.deque.__doc__ deque(iterable) --> deque object Build an ordered collection accessible from endpoints only. -- Comment By: Skip Montanaro (montanaro) Date: 2004-12-17 16:05 Message: Logged In: YES user_id=44345 Pydoc generates documentation based upon what it finds in docstrings and function signatures. It can't get at the signatures of functions written in C. In Python 2.4 pydoc generates a link to a local or online version of the docs for the subject module: NAME datetime - Fast implementation of the datetime type. FILE /Users/skip/local/lib/python2.5/lib-dynload/datetime.so MODULE DOCS http://www.python.org/doc/current/lib/module-datetime.html CLASSES __builtin__.object date datetime ... I think that's the best that can be done short of macroizing the hell out of C extension modules to allow function signatures to be captured as attributes attached to the functions, similar to what GNU Emacs did many years ago. Correct me if I'm wrong, but I don't think we want to go down that path (take a peek at the Emacs source if you are in doubt). -- Comment By: Mike Meyer (mwm) Date: 2004-12-17 15:23 Message: Logged In: YES user_id=93910 You're right - I was just blind when reading the module documenation. It would still be nice if I could get that information from pydoc/help, though. -- Comment By: Tim Peters (tim_one) Date: 2004-12-17 14:56 Message: Logged In: YES user_id=31435 I'm not sure which docs you're looking at. I'm looking at the Python docs , like here: http://docs.python.org/lib/datetime-date.html That seems very clear to me: """ class date(year, month, day) All arguments are required. Arguments may be ints or longs, in the following ranges: MINYEAR <= year <= MAXYEAR 1 <= month <= 12 1 <= day <= number of days in the given month and year If an argument outside those ranges is given, ValueError is raised. """ There are equally precise docs for all the datetime.* classes. For example, you mentioned time: """ class time(hour[, minute[, second[, microsecond[, tzinfo) All arguments are optional. tzinfo may be None, or an instance of a tzinfo subclass. The remaining arguments may be ints or longs, in the following ranges: 0 <= hour < 24 0 <= minute < 60 0 <= second < 60 0 <= microsecond < 100. If an argument outside those ranges is given, ValueError is raised. All default to 0 except tzinfo, which defaults to None. """ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1084279 ] status of small floats in xml-rpc ?
Bugs item #1084279, was opened at 2004-12-13 05:07
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Nobody/Anonymous (nobody)
Summary: status of small floats in xml-rpc ?
Initial Comment:
Hi,
I've been reading through the xmlrpclib.py code to see
that floats are marshalled the following way:
def dump_double(self, value, write):
write("")
write(repr(value))
write("\n")
dispatch[FloatType] = dump_double
Using repr() means that small or big floats, for
example, will be output using the exponent notation:
>>> repr(2**-15)
'3.0517578125e-05'
Unfortunately, the XML-RPC specification does not allow
this notation:
"At this time, only decimal point notation is allowed,
a plus or a minus, followed by any number of numeric
characters, followed by a period and any number of
numeric characters. Whitespace is not allowed. The
range of allowable values is implementation-dependent,
is not specified."
(http://www.xmlrpc.com/spec)
Thus floats marshalled using xmlrpclib may not be
readable using other XML-RPC implementations.
(I don't have any concrete data about this though)
--
Comment By: Tim Peters (tim_one)
Date: 2004-12-17 15:30
Message:
Logged In: YES
user_id=31435
FWIW, I'd leave this alone. The XML-RPC spec is braindead
when it comes to floats, and any implementation that didn't
accept scientific notation would have to go out of its way to
cripple the facilities all languages with a string->double
function supply.
Raymond, under any IEEE-conforming string->double
implementation, eval(repr(x))==x will hold provided that repr
(x) be roughly correct to at least 17 significant decimal digits,
and that x is finite. It doesn't matter whether the string uses
exponent notation. OTOH, IIRC Python got in trouble once
with some old Solaris string->double C routine that went
insane if the string had "too many" characters. Indeed,
making bad assumptions about maximum string length seems
a lot more likely to me than that someone has a string-
>double routine that can't deal with exponents.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-16 05:32
Message:
Logged In: YES
user_id=80475
After more thought, I'm concerned that switching to full
decimal notation will break the guarantee eval(repr(x))==x.
Also, Skip's thoughts seem reasonable. Rather than
switching to a non-compact format, it may be best to way for
the spec to catchup with real implementations.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 17:19
Message:
Logged In: YES
user_id=80475
Various slightly unsatisfactory answers:
* It started out that way because that's what C did.
* It stayed that way because no one has requested it
* It may be that outside of XMLRPC there are very few valid
use cases.
* Future needs can be met by the decimal module.
--
Comment By: Antoine Pitrou (pitrou)
Date: 2004-12-13 14:04
Message:
Logged In: YES
user_id=133955
I'm gonna ask a stupid question (I'm quite a beginner in
Python). Why isn't there a %f-life formatting code for doing
just what you wrote - printing the float in full precision
in non-exponent format ?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 13:12
Message:
Logged In: YES
user_id=80475
The thought was "be liberal in what you accept and be strict
on was is emitted." Still, the question is valid.
For C, it looks like strtod() is at the root of everything
converting from floats. The spec lays no limits on the
input format (exponents vs full decimal representation).
Instead, it just checks that the result is inside the range
of representable values and did not underflow.
Some experiments with MSC6 confirm that the full range may
be entered as regular decimals. Experiments with Perl show
the same result. I suspect all TCL and Ruby also have
strtod() at the core.
--
Comment By: Skip Montanaro (montanaro)
Date: 2004-12-13 10:38
Message:
Logged In: YES
user_id=44345
I understand what you''re doing, but I wonder if in the
process interoperability with other XML-RPC implementations
might actually get worse. While the spec doesn't support
exponential notation, most programming languages do, and
probably happily accept "1.234e-147" as a floating point
input. Python seems not to have problems accepting floating
point input
[ python-Bugs-1083645 ] Tests fail instead of skip
Bugs item #1083645, was opened at 2004-12-11 15:06 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Detlef Vollmann (dvch) Assigned to: Nobody/Anonymous (nobody) Summary: Tests fail instead of skip Initial Comment: On Linux, with threads disabled (--with-threads=no), the tests test_imp, test_list and test_userlist fail instead of skipping. -- >Comment By: Brett Cannon (bcannon) Date: 2004-12-17 20:33 Message: Logged In: YES user_id=357491 Can you run these tests individually and save the output to see how they are failing? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1087418 ] long int bitwise ops speedup (patch included)
Feature Requests item #1087418, was opened at 2004-12-18 00:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087418&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: long int bitwise ops speedup (patch included) Initial Comment: The 'inner loop' for applying bitwise ops to longs is quite inefficient. The improvement in the attached diff is - 'a' is never shorter than 'b' (result: only test 1 loop index condition instead of 3) - each operation ( & | ^ ) has its own loop, instead of switch inside loop - I found that, when this is done, a lot of things can be simplified, resulting in further speedup, and the resulting code is not very much longer than before (my libpython2.4.dll .text got 140 bytes longer). Operations on longs of a few thousand bits appear to be 2 ... 2.5 times faster with this patch. I'm not 100% sure the code is right, but it passes test_long.py, anyway. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087418&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1081045 ] readline module doesn't build on MacOSX
Bugs item #1081045, was opened at 2004-12-07 18:19 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: readline module doesn't build on MacOSX Initial Comment: Recent changes to either configure or setup.py seem to have conspired to prevent the readline module from building on MacOSX. I configured and built with LDFLAGS='-L/sw/lib' CPPFLAGS='-I/sw/include' ../ configure '--prefix=/Users/skip/local' make The relevant readline bits are in /sw/... but the module is not built. The following bits containing /sw grep out of the generated Makefile: INSTALL=/sw/bin/install -c CPPFLAGS= -I. -I$(srcdir)/Include -I/sw/include LDFLAGS=-L/sw/lib CONFIG_ARGS='--prefix=/Users/skip/local' 'CPPFLAGS=-I/sw/include' 'LDFLAGS=-L/sw/lib' Assigning to Brett since he touched this most recently. Skip -- >Comment By: Brett Cannon (bcannon) Date: 2004-12-17 23:56 Message: Logged In: YES user_id=357491 I was able to reproduce the problem of the environment variable returning None for a short time (it for some reason stopped doing that and started to do what I expected). While I could, though, I was able to get the right values using distutils.sysconfig.get_config_var(). The attached file adds a little bit more debugging output and also switches over to using distutils.sysconfig.get_config_var() instead of sys.getenv(). Let me know if that fixes the problem. -- Comment By: Brett Cannon (bcannon) Date: 2004-12-10 11:44 Message: Logged In: YES user_id=357491 I have uploaded a patch to add some debugging output. Can you run make and let me know what it outputs (might need to touch a file to trigger the need for setup.py to execute)? I need to know exactly what the environment variables are set to when they are parsed and what setup.py ends up with for its library and include directories. -- Comment By: Skip Montanaro (montanaro) Date: 2004-12-07 18:46 Message: Logged In: YES user_id=44345 More on this... Sticking a print of lib_dirs just before setup.py checks for readline shows that /sw/lib is not in that list. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
