[ python-Bugs-1251528 ] smtplib and email.py
Bugs item #1251528, was opened at 2005-08-03 19:50 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251528&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Cosmin Nicolaescu (cosminn) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib and email.py Initial Comment: If the script calling smtplib.SMTP() is called email.py smtplib breaks and compiles email.py as a module. I could not find any mention of this in the documentation, and while this is not a big deal, it should be documented. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-08-11 00:36 Message: Logged In: YES user_id=341410 smtplib imports a portion of the standard library module email . By naming your module 'email', you are masking the standard library 'email' that smtplib is trying to import. This is a common problem among new users of Python. Before naming your modules using an obviously common name, take a peek at the modules that are currently available (a listing is available here: http://docs.python.org/modindex.html ). Future versions of Python may fix such issues, but this is not guaranteed. Suggested close. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251528&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1251528 ] smtplib and email.py
Bugs item #1251528, was opened at 2005-08-03 21:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251528&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Cosmin Nicolaescu (cosminn) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib and email.py Initial Comment: If the script calling smtplib.SMTP() is called email.py smtplib breaks and compiles email.py as a module. I could not find any mention of this in the documentation, and while this is not a big deal, it should be documented. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-11 02:40 Message: Logged In: YES user_id=80475 Thanks Josiah. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-08-11 02:36 Message: Logged In: YES user_id=341410 smtplib imports a portion of the standard library module email . By naming your module 'email', you are masking the standard library 'email' that smtplib is trying to import. This is a common problem among new users of Python. Before naming your modules using an obviously common name, take a peek at the modules that are currently available (a listing is available here: http://docs.python.org/modindex.html ). Future versions of Python may fix such issues, but this is not guaranteed. Suggested close. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251528&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1256669 ] Significant memory leak with PyImport_ReloadModule
Bugs item #1256669, was opened at 2005-08-11 12:49 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=1256669&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ben Held (bheld) Assigned to: Nobody/Anonymous (nobody) Summary: Significant memory leak with PyImport_ReloadModule Initial Comment: Having recently upgraded to Python 2.4, I am having a large memory leak with the following code built with VC++ 6.0: PyObject *pName, *pModule; Py_Initialize(); pName = PyString_FromString(argv[1]); pModule = PyImport_Import(pName); Py_DECREF(pName); PyObject* pModule2 = PyImport_ReloadModule(pModule); Py_DECREF(pModule2); Py_DECREF(pModule); Py_Finalize(); return 0; I get leaks of over 500 kb. I have another program which is much more complex, in which every call to PyImport_ReloadModule is leaking 200+ kb, even though I am calling Py_DECREF correctly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1
Bugs item #1178484, was opened at 2005-04-07 14:33
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Timo Linna (tilinna)
Assigned to: Martin v. Löwis (loewis)
Summary: Erroneous line number error in Py2.4.1
Initial Comment:
For some reason Python 2.3.5 reports the error in the
following program correctly:
File "C:\Temp\problem.py", line 7
SyntaxError: unknown decode error
..whereas Python 2.4.1 reports an invalid line number:
File "C:\Temp\problem.py", line 2
SyntaxError: unknown decode error
- problem.py starts -
# -*- coding: ascii -*-
"""
Foo bar
"""
# Ä is not allowed in ascii coding
- problem.py ends -
Without the encoding declaration both Python versions
report the usual deprecation warning (just like they
should be doing).
My environment: Windows 2000 + SP3.
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2005-08-11 16:04
Message:
Logged In: YES
user_id=89016
Somehow I forgot to upload the patch. Here it is
(diff2.txt). I'd like this patch to go into 2.4.2.
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-05-19 21:06
Message:
Logged In: YES
user_id=89016
> Walter, as I've said before: I know that you need buffering
> for the UTF-x readline support, but I don't see a
> requirement for it in most of the other codecs
The *charbuffer* is required for readline support, but the
*bytebuffer* is required for any non-charmap codec.
To have different buffering modes we'd either need a flag in
the StreamReader or use different classes, i.e. a class
hierarchy like the following:
StreamReader
UnbufferedStreamReader
CharmapStreamReader
ascii.StreamReader
iso_8859_1.StreamReader
BufferedStreamReader
utf_8.StreamReader
I don't think that we should introduce such a big change in
2.4.x. Furthermore there is another problem: The 2.4
buffering code automatically gives us universal newline
support. If you have a file foo.txt containing "a\rb", with
Python 2.4 you get:
>>> list(codecs.open("foo.txt", "rb", "latin-1"))
[u'a\r', u'b']
But with Python 2.3 you get:
>>> list(codecs.open("foo.txt", "rb", "latin-1"))
[u'a\rb']
If we would switch to the old StreamReader for the charmap
codecs, suddenly the stream reader for e.g. latin-1 and
UTF-8 would behave differently. Of course we could change
the buffering stream reader to only split lines on "\n", but
this would change functionality again.
> Your argument about applications making implications on the
> file position after having used .readline() is true, but
> still many applications rely on this behavior which is not
> as far fetched as it may seem given that they normally only
> expect 8-bit data.
If an application doesn't mix calls to read() with calls to
readline() (or different size values in these calls), the
change in behaviour from 2.3 to 2.4 shouldn't be this big.
No matter what we decide for the codecs, the tokenizer is
broken and should be fixed.
> Wouldn't it make things a lot safer if we only use buffering
> per default in the UTF-x codecs and revert back to the old
> non-buffered behavior for the other codecs which has worked
> well in the past ?!
Only if we'd drop the additional functionality added in 2.4.
(universal
newline support, the chars argument for read() and the
keepends argument for readline().), which I think could only
be done for 2.5.
> About your patch:
>
> * Please explain what firstline is supposed to do
> (preferably in the doc-string).
OK, I've added an explanation in the docstring.
> * Why is firstline always set in .readline() ?
firstline is only supposed to be used by readline(). We could
rename the argument to _firstline to make it clear that this is
a private parameter, or introduce a new method _read() that
has a firstline parameter. Then read() calls _read() with
firstline==False and readline() calls _read() with
firstline==True.
The purpose of firstline is to make sure that if an input
stream has
its first decoding error in line n, that the
UnicodeDecodeError will only be raised by the n'th call to
readline().
> * Please remove the print repr()
OK, done.
> * You cannot always be sure that exc has a .start attribute,
> so you need to accomocate for this situation as well
I don't understand that. A UnicodeDecodeError is created by
PyUnicodeDecodeError_Create() in exceptions.c, so any
UnicodeDecodeError instance without a start attribute would
be severely broken.
Thanks for reviewing the p
[ python-Bugs-1249749 ] Encodings and aliases do not match runtime
Bugs item #1249749, was opened at 2005-08-01 13:23
Message generated for change (Comment added) made by liturgist
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249749&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: liturgist (liturgist)
Assigned to: Nobody/Anonymous (nobody)
Summary: Encodings and aliases do not match runtime
Initial Comment:
2.4.1 documentation has a list of standard encodings in
4.9.2. However, this list does not seem to match what
is returned by the runtime. Below is code to dump out
the encodings and aliases. Please tell me if anything
is incorrect.
In some cases, there are many more valid aliases than
listed in the documentation. See 'cp037' as an example.
I see that the identifiers are intended to be case
insensitive. I would prefer to see the documentation
provide the identifiers as they will appear in
encodings.aliases.aliases. The only alias containing
any upper case letters appears to be 'hp_roman8'.
$ cat encodingaliases.py
#!/usr/bin/env python
import sys
import encodings
def main():
enchash = {}
for enc in encodings.aliases.aliases.values():
enchash[enc] = []
for encalias in encodings.aliases.aliases.keys():
enchash[encodings.aliases.aliases[encalias]].append(encalias)
elist = enchash.keys()
elist.sort()
for enc in elist:
print enc, enchash[enc]
if __name__ == '__main__':
main()
sys.exit(0)
13:12 pwatson [
ruth.knightsbridge.com:/home/pwatson/src/python ] 366
$ ./encodingaliases.py
ascii ['iso_ir_6', 'ansi_x3_4_1968', 'ibm367',
'iso646_us', 'us', 'cp367', '646', 'us_ascii',
'csascii', 'ansi_x3.4_1986', 'iso_646.irv_1991',
'ansi_x3.4_1968']
base64_codec ['base_64', 'base64']
big5 ['csbig5', 'big5_tw']
big5hkscs ['hkscs', 'big5_hkscs']
bz2_codec ['bz2']
cp037 ['ebcdic_cp_wt', 'ebcdic_cp_us', 'ebcdic_cp_nl',
'037', 'ibm039', 'ibm037', 'csibm037', 'ebcdic_cp_ca']
cp1026 ['csibm1026', 'ibm1026', '1026']
cp1140 ['1140', 'ibm1140']
cp1250 ['1250', 'windows_1250']
cp1251 ['1251', 'windows_1251']
cp1252 ['windows_1252', '1252']
cp1253 ['1253', 'windows_1253']
cp1254 ['1254', 'windows_1254']
cp1255 ['1255', 'windows_1255']
cp1256 ['1256', 'windows_1256']
cp1257 ['1257', 'windows_1257']
cp1258 ['1258', 'windows_1258']
cp424 ['ebcdic_cp_he', 'ibm424', '424', 'csibm424']
cp437 ['ibm437', '437', 'cspc8codepage437']
cp500 ['csibm500', 'ibm500', '500', 'ebcdic_cp_ch',
'ebcdic_cp_be']
cp775 ['cspc775baltic', '775', 'ibm775']
cp850 ['ibm850', 'cspc850multilingual', '850']
cp852 ['ibm852', '852', 'cspcp852']
cp855 ['csibm855', 'ibm855', '855']
cp857 ['csibm857', 'ibm857', '857']
cp860 ['csibm860', 'ibm860', '860']
cp861 ['csibm861', 'cp_is', 'ibm861', '861']
cp862 ['cspc862latinhebrew', 'ibm862', '862']
cp863 ['csibm863', 'ibm863', '863']
cp864 ['csibm864', 'ibm864', '864']
cp865 ['csibm865', 'ibm865', '865']
cp866 ['csibm866', 'ibm866', '866']
cp869 ['csibm869', 'ibm869', '869', 'cp_gr']
cp932 ['mskanji', '932', 'ms932', 'ms_kanji']
cp949 ['uhc', 'ms949', '949']
cp950 ['ms950', '950']
euc_jis_2004 ['eucjis2004', 'jisx0213', 'euc_jis2004']
euc_jisx0213 ['eucjisx0213']
euc_jp ['eucjp', 'ujis', 'u_jis']
euc_kr ['ksc5601', 'korean', 'euckr', 'ksx1001',
'ks_c_5601', 'ks_c_5601_1987', 'ks_x_1001']
gb18030 ['gb18030_2000']
gb2312 ['chinese', 'euc_cn', 'csiso58gb231280',
'iso_ir_58', 'euccn', 'eucgb2312_cn', 'gb2312_1980',
'gb2312_80']
gbk ['cp936', 'ms936', '936']
hex_codec ['hex']
hp_roman8 ['csHPRoman8', 'r8', 'roman8']
hz ['hzgb', 'hz_gb_2312', 'hz_gb']
iso2022_jp ['iso2022jp', 'iso_2022_jp', 'csiso2022jp']
iso2022_jp_1 ['iso_2022_jp_1', 'iso2022jp_1']
iso2022_jp_2 ['iso_2022_jp_2', 'iso2022jp_2']
iso2022_jp_2004 ['iso_2022_jp_2004', 'iso2022jp_2004']
iso2022_jp_3 ['iso_2022_jp_3', 'iso2022jp_3']
iso2022_jp_ext ['iso2022jp_ext', 'iso_2022_jp_ext']
iso2022_kr ['iso_2022_kr', 'iso2022kr', 'csiso2022kr']
iso8859_10 ['csisolatin6', 'l6', 'iso_8859_10_1992',
'iso_ir_157', 'iso_8859_10', 'latin6']
iso8859_11 ['iso_8859_11', 'thai', 'iso_8859_11_2001']
iso8859_13 ['iso_8859_13']
iso8859_14 ['iso_celtic', 'iso_ir_199', 'l8',
'iso_8859_14_1998', 'iso_8859_14', 'latin8']
iso8859_15 ['iso_8859_15']
iso8859_16 ['iso_8859_16_2001', 'l10', 'iso_ir_226',
'latin10', 'iso_8859_16']
iso8859_2 ['l2', 'csisolatin2', 'iso_ir_101',
'iso_8859_2', 'iso_8859_2_1987', 'latin2']
iso8859_3 ['iso_8859_3_1988', 'l3', 'iso_ir_109',
'csisolatin3', 'iso_8859_3', 'latin3']
iso8859_4 ['csisolatin4', 'l4', 'iso_ir_110',
'iso_8859_4', 'iso_8859_4_1988', 'latin4']
iso8859_5 ['iso_8859_5_1988', 'iso_8859_5', 'cyrillic',
'csisolatincyrillic', 'iso_ir_144']
iso8859_6 ['iso_8859_6_1987', 'iso_ir_127',
'csisolatinarabic', 'asmo_708', 'iso_8859_6',
'ecma_114', 'arabic']
iso8859_7 ['ecma_118', 'greek8',
[ python-Bugs-1256786 ] slice object uses -1 as exclusive end-bound
Bugs item #1256786, was opened at 2005-08-11 08:08 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=1256786&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bryan G. Olson (bryango) Assigned to: Nobody/Anonymous (nobody) Summary: slice object uses -1 as exclusive end-bound Initial Comment: The slice object passed to __getitem__ or __setitem__ reports an incorrect 'stop' value when the step is negative and the slice includes the 0 index. If one then actually tries to slice with what slice.indices returns, the result is wrong. Here's a demo: class BuggerAll: def __init__(self, somelist): self.sequence = somelist[:] def __getitem__(self, key): if isinstance(key, slice): start, stop, step = key.indices(len(self.sequence)) # print 'Slice says start, stop, step are:', start, stop, step return self.sequence[start : stop : step] print range(10) [None : None : -2] print BuggerAll(range(10))[None : None : -2] The above should print the same sequence twice, but actually prints: [9, 7, 5, 3, 1] [] Un-commenting the print statement in __getitem__ shows: Slice says start, stop, step are: 9 -1 -2 The problem is the stop value of -1. The slice object seems to think that -1 is a valid exclusive-end-bound, but when slicing, Python interprets negative numbers as an offset from the high end of the sequence. That is, range(10)[9 : -1 : -2] is the same as, range(10)[[9 : 9 : -2] which is the empty list. So what should the slice.indices return in this case, so that slicing with the returned values will work correctly? My experiments indicate: The start value can be any of: None, any integer >= 9, -1 The stop value can be either: None, any integer <= -11 Step is correct; it must be:-2 My favorite choice here is (9, None, -2). The doc for slice.indices currently says: This method takes a single integer argument /length/ and computes information about the extended slice that the slice object would describe if applied to a sequence of length items. It returns a tuple of three integers; respectively these are the /start/ and /stop/ indices and the /step/ or stride length of the slice. Missing or out-of-bounds indices are handled in a manner consistent with regular slices. http://docs.python.org/ref/types.html So using (9, None, -2) would require changing both the code and the doc (because None is not an integer). A stop value of -11 (or less) would require changing only the code. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256786&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1
Bugs item #1178484, was opened at 2005-04-07 14:33
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Timo Linna (tilinna)
Assigned to: Martin v. Löwis (loewis)
Summary: Erroneous line number error in Py2.4.1
Initial Comment:
For some reason Python 2.3.5 reports the error in the
following program correctly:
File "C:\Temp\problem.py", line 7
SyntaxError: unknown decode error
..whereas Python 2.4.1 reports an invalid line number:
File "C:\Temp\problem.py", line 2
SyntaxError: unknown decode error
- problem.py starts -
# -*- coding: ascii -*-
"""
Foo bar
"""
# Ä is not allowed in ascii coding
- problem.py ends -
Without the encoding declaration both Python versions
report the usual deprecation warning (just like they
should be doing).
My environment: Windows 2000 + SP3.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-08-11 17:22
Message:
Logged In: YES
user_id=1188172
Would it be appropriate to raise priority, then, to ensure
this doesn't get overlooked before 2.4.2?
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-08-11 16:04
Message:
Logged In: YES
user_id=89016
Somehow I forgot to upload the patch. Here it is
(diff2.txt). I'd like this patch to go into 2.4.2.
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-05-19 21:06
Message:
Logged In: YES
user_id=89016
> Walter, as I've said before: I know that you need buffering
> for the UTF-x readline support, but I don't see a
> requirement for it in most of the other codecs
The *charbuffer* is required for readline support, but the
*bytebuffer* is required for any non-charmap codec.
To have different buffering modes we'd either need a flag in
the StreamReader or use different classes, i.e. a class
hierarchy like the following:
StreamReader
UnbufferedStreamReader
CharmapStreamReader
ascii.StreamReader
iso_8859_1.StreamReader
BufferedStreamReader
utf_8.StreamReader
I don't think that we should introduce such a big change in
2.4.x. Furthermore there is another problem: The 2.4
buffering code automatically gives us universal newline
support. If you have a file foo.txt containing "a\rb", with
Python 2.4 you get:
>>> list(codecs.open("foo.txt", "rb", "latin-1"))
[u'a\r', u'b']
But with Python 2.3 you get:
>>> list(codecs.open("foo.txt", "rb", "latin-1"))
[u'a\rb']
If we would switch to the old StreamReader for the charmap
codecs, suddenly the stream reader for e.g. latin-1 and
UTF-8 would behave differently. Of course we could change
the buffering stream reader to only split lines on "\n", but
this would change functionality again.
> Your argument about applications making implications on the
> file position after having used .readline() is true, but
> still many applications rely on this behavior which is not
> as far fetched as it may seem given that they normally only
> expect 8-bit data.
If an application doesn't mix calls to read() with calls to
readline() (or different size values in these calls), the
change in behaviour from 2.3 to 2.4 shouldn't be this big.
No matter what we decide for the codecs, the tokenizer is
broken and should be fixed.
> Wouldn't it make things a lot safer if we only use buffering
> per default in the UTF-x codecs and revert back to the old
> non-buffered behavior for the other codecs which has worked
> well in the past ?!
Only if we'd drop the additional functionality added in 2.4.
(universal
newline support, the chars argument for read() and the
keepends argument for readline().), which I think could only
be done for 2.5.
> About your patch:
>
> * Please explain what firstline is supposed to do
> (preferably in the doc-string).
OK, I've added an explanation in the docstring.
> * Why is firstline always set in .readline() ?
firstline is only supposed to be used by readline(). We could
rename the argument to _firstline to make it clear that this is
a private parameter, or introduce a new method _read() that
has a firstline parameter. Then read() calls _read() with
firstline==False and readline() calls _read() with
firstline==True.
The purpose of firstline is to make sure that if an input
stream has
its first decoding error in line n, that the
UnicodeDecodeError will only be raised by the n'th call to
readline().
> * Please remove the print repr()
OK, done.
> * You cannot always be sure that exc has a .start att
[ python-Bugs-1255218 ] "appropriately decorated" is undefined in MultiFile.push doc
Bugs item #1255218, was opened at 2005-08-09 15:07 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1255218&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: "appropriately decorated" is undefined in MultiFile.push doc Initial Comment: At http://docs.python.org/lib/MultiFile-objects.html we read: push( str) Push a boundary string. When an appropriately decorated version of this boundary is found as an input line, it will be interpreted as a section-divider or end-marker. ... But this presumes that "appropriately decorated" is understood, which it won't be until multifile is understood. How about following that sentence with something like: (Appropriate decoration is determined by the section_divider and end_marker methods.) -- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-08-11 13:11 Message: Logged In: YES user_id=593130 I agree that the sentence is confusing in its appropriate context. An alternative to the forward reference to the section_divider and end_marker methods is to move the entries for those methods just above the entry for the push method. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1255218&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1255395 ] float('-inf')
Bugs item #1255395, was opened at 2005-08-09 21:15
Message generated for change (Comment added) made by tjreedy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1255395&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Platform-specific
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Steven Bird (stevenbird)
Assigned to: Nobody/Anonymous (nobody)
Summary: float('-inf')
Initial Comment:
Python 2.4.1 on Windows raises "ValueError: invalid
literal for float(): -inf", though this works just fine
on unix distributions of Python 2.4.1.
--
>Comment By: Terry J. Reedy (tjreedy)
Date: 2005-08-11 13:33
Message:
Logged In: YES
user_id=593130
Snide comments are out of place here. Standard C 89 is
generally considered one language even though it has many
platform dependencies. Heroic efforts, mostly volunteer, have
gone into masking many platform variations. (For instance, look
thru the C sources for system/compiler #ifdefs.) These efforts
continue.
http://docs.python.org/lib/built-in-funcs.html, float([x]) says
"Note: When passing in a string, values for NaN and Infinity may
be returned, depending on the underlying C library. The specific
set of strings accepted which cause these values to be returned
depends entirely on the C library and is known to vary."
Please read the docs before claiming that documented behavior
is a bug.
--
Comment By: Michael Hudson (mwh)
Date: 2005-08-10 08:56
Message:
Logged In: YES
user_id=6656
Well, everything to do with special floating point values is a platform
dependent crapshoot (in fact, if you want to read more, googling for
"platform dependent crapshoot" works quite well...).
Are you interested in working on a patch? It's probably not straightforward
at all.
--
Comment By: Steven Bird (stevenbird)
Date: 2005-08-10 08:49
Message:
Logged In: YES
user_id=195736
Oh, I thought Python 2.4.1 was the same language, regardless
of which platform it was running on. I must be missing
something here.
--
Comment By: Michael Hudson (mwh)
Date: 2005-08-10 08:35
Message:
Logged In: YES
user_id=6656
At most, this is a feature request (why did you think it would work?).
Floating point to string (and vice versa) conversions are done by the C
library implementation, and sadly they are no consistent (you'll notice that
printing an infinite value on windows doesn't print out 'inf' either).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1255395&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1249615 ] isinstance() fails depending on how modules imported
Bugs item #1249615, was opened at 2005-08-01 10:54 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249615&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Hugh Gibson (hgibson50) Assigned to: Nobody/Anonymous (nobody) Summary: isinstance() fails depending on how modules imported Initial Comment: I have found an inconsistency with instance type checking dependent on how modules are imported. Using Windows 2000, Python 2.4.1. Source files are attached. Unzip preserving paths. To run, open a cmd window and set PythonPath to the location of the "system" folder. Run ServerRun.py. The program creates two class instances in two different modules, then calls a class function on one instance which takes as parameter the second instance. A call to isinstance to check if the parameter is of the correct class fails. If a parameter is passed to ServerRun.py then the class module is imported in a different way (specifying the path to the class) and the isinstance check succeeds. The output shows that before the call to the class function, an isinstance() call succeeds in both cases. There is obviously an easy fix in code, but I think that isinstance checking should not depend on how modules are imported. And, if I am using an incorrect module import sequence, that sequence should be disallowed. Sample output (also showing Windows 2000 version) is: Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\system\server>set pythonpath=c:\system C:\system\server>serverrun ServerRun: oNew.__class__ == Stream.CElement == isinstance(oNew, Stream.CElement) == True AddField(): oNew.__class__ == CElement == isinstance(oNew, CElement) == False C:\system\server>serverrun 1 ServerRun: oNew.__class__ == Stream.CElement == isinstance(oNew, Stream.CElement) == True AddField(): oNew.__class__ == CElement == isinstance(oNew, CElement) == True C:\system\server> -- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-08-11 13:43 Message: Logged In: YES user_id=593130 adding the resolution as 'invalid' based on the discussion here and elsewhere -- Comment By: Hugh Gibson (hgibson50) Date: 2005-08-03 03:45 Message: Logged In: YES user_id=732318 Thanks for the concise example. I can see why our code fails. If I check each class instance using its own function then it will succeed, but if I check using another instance's function then it fails because as you say the module is imported differently. Putting a statement at the start of the class module: print __name__ shows two imports of the class module in the failure mode, with different names. So an easy cross-check to make sure we are being consistent about importing is: assert(__name__ == "server.Stream.Stream") This fires if the incorrect sequence is used to import the module. This is a simple check which can be added to every module and will guard against incorrect imports in future. I suppose that I can't complain about flexibility in Python which allows all sorts of tricks. In this case I was handed just a bit too much rope. But the simple assert, added to our coding standards and code, will prevent any problems in future. Thanks. Hugh -- Comment By: Walter Dörwald (doerwalter) Date: 2005-08-02 09:14 Message: Logged In: YES user_id=89016 The problem is not isinstance() per se, but the fact that you import one Python script as two different modules. A simple demo might look like this: class Foo: pass import bug print isinstance(Foo(), bug.Foo) Put this in bug.py and run "python bug.py" and you'll get: True False So I think this bug should be closed. -- Comment By: Hugh Gibson (hgibson50) Date: 2005-08-02 09:00 Message: Logged In: YES user_id=732318 The case I found here is particularly worrying because I'm doing the isinstance() check in the module that contains the class. The success of the check depends on how that module was imported into other modules. The two cases are: from server.Stream import Stream from Stream import Stream We found this problem in a large application under development. Unit testing of the class succeeded because of the way the class module was imported. But the application itself failed because of the way one module imported the class module. The failure was obvious in our application but
[ python-Bugs-1066546 ] test_pwd fails on 64bit system (Opteron)
Bugs item #1066546, was opened at 2004-11-15 03:34
Message generated for change (Comment added) made by heffler
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_pwd fails on 64bit system (Opteron)
Initial Comment:
test test_pwd failed -- Traceback (most recent call last):
File "/tmp/miki/Python-2.4b2/Lib/test/test_pwd.py",
line 42, in test_values
self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum
$ cat /proc/version
Linux version 2.4.21-20.ELsmp
([EMAIL PROTECTED]) (gcc version 3.2.3
20030502 (Red Hat Linux 3.2.3-42)) #1 SMP Wed Aug 18
20:34:58 EDT 2004
Processor is AMD Opteron 2.4MHz
--
Comment By: Marvin Heffler (heffler)
Date: 2005-08-11 13:19
Message:
Logged In: YES
user_id=298758
I think I figued out the problem with python handling uids and
gids greater than 2147483647 when using the grp.getgrgid
and pwd.getpwuid functions. Both of the functions call
PyArg_ParseTuple with a type of "i", thus indicating the
argument is a signed integer. Instead they should be
using "I" (upper-case i) for an unsigned integer. The fix is
fairly simple. Here are the two patches necessary to the
python source:
diff -Naur Python-2.4.orig/Modules/grpmodule.c Python-
2.4/Modules/grpmodule.c
--- Python-2.4.orig/Modules/grpmodule.c 2004-01-20
16:06:00.0 -0500
+++ Python-2.4/Modules/grpmodule.c 2005-08-11
13:36:48.0 -0400
@@ -87,7 +87,7 @@
{
int gid;
struct group *p;
-if (!PyArg_ParseTuple(args, "i:getgrgid", &gid))
+if (!PyArg_ParseTuple(args, "I:getgrgid", &gid))
return NULL;
if ((p = getgrgid(gid)) == NULL) {
PyErr_Format(PyExc_KeyError, "getgrgid(): gid not
found: %d", gid);
diff -Naur Python-2.4.orig/Modules/pwdmodule.c Python-
2.4/Modules/pwdmodule.c
--- Python-2.4.orig/Modules/pwdmodule.c 2004-01-20
16:07:23.0 -0500
+++ Python-2.4/Modules/pwdmodule.c 2005-08-11
13:36:27.0 -0400
@@ -104,7 +104,7 @@
{
int uid;
struct passwd *p;
- if (!PyArg_ParseTuple(args, "i:getpwuid", &uid))
+ if (!PyArg_ParseTuple(args, "I:getpwuid", &uid))
return NULL;
if ((p = getpwuid(uid)) == NULL) {
PyErr_Format(PyExc_KeyError,
Hopefully, someone from the python project can verify my
patch and get it incorporated into a future release.
--
Comment By: Clark Mobarry (cmobarry)
Date: 2005-08-03 13:40
Message:
Logged In: YES
user_id=1035073
The same error occurs for an Intel P4-521 processor running
RedHat Enterprise Linux WS v4 Intel EM64T 64bit.
$ cat /proc/version
Linux version 2.6.9-5.ELsmp ([EMAIL PROTECTED])
(gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)) #1 SMP
Wed Jan 5 19:29:47 EST 2005
test test_grp failed -- Traceback (most recent call last):
File
"/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_grp.py",
line 29, in test_values
e2 = grp.getgrgid(e.gr_gid)
OverflowError: signed integer is greater than maximum
test test_pwd failed -- Traceback (most recent call last):
File
"/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_pwd.py",
line 42, in test_values
self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum
--
Comment By: Miki Tebeka (tebeka)
Date: 2005-03-17 03:20
Message:
Logged In: YES
user_id=358087
I've tried the patch - no luck :-(
I'm stealing time on these machines since they belong to
another group.
However I see that SF's compile farm
(http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1)
have an AMD64 host (amd64-linux1)
Maybe you can shorten the loop ...
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-03-14 16:17
Message:
Logged In: YES
user_id=89016
On a 32bit system adding the line
nobody:x:4294967294:65534:nobody:/:/bin/false
to /etc/passwd pwd.getpwall() gives me an entry:
('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false')
and
pwd.getpwuid(-2)
gives me
('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false')
Maybe for 64bit systems the SETI macro should use
PyLong_FromUnsignedLong() instead of PyInt_FromLong()? Can
you try the following patch?
--
Comment By: Miki Tebeka (tebeka)
Date: 2004-11-17 02:43
Message:
Logged In: YES
[ python-Bugs-1255395 ] float('-inf')
Bugs item #1255395, was opened at 2005-08-09 20:15
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1255395&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Platform-specific
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Steven Bird (stevenbird)
Assigned to: Nobody/Anonymous (nobody)
Summary: float('-inf')
Initial Comment:
Python 2.4.1 on Windows raises "ValueError: invalid
literal for float(): -inf", though this works just fine
on unix distributions of Python 2.4.1.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-11 13:21
Message:
Logged In: YES
user_id=80475
FWIW, googling for the phrase does lead directly to revelant
discussion of the issues.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-08-11 12:33
Message:
Logged In: YES
user_id=593130
Snide comments are out of place here. Standard C 89 is
generally considered one language even though it has many
platform dependencies. Heroic efforts, mostly volunteer, have
gone into masking many platform variations. (For instance, look
thru the C sources for system/compiler #ifdefs.) These efforts
continue.
http://docs.python.org/lib/built-in-funcs.html, float([x]) says
"Note: When passing in a string, values for NaN and Infinity may
be returned, depending on the underlying C library. The specific
set of strings accepted which cause these values to be returned
depends entirely on the C library and is known to vary."
Please read the docs before claiming that documented behavior
is a bug.
--
Comment By: Michael Hudson (mwh)
Date: 2005-08-10 07:56
Message:
Logged In: YES
user_id=6656
Well, everything to do with special floating point values is a platform
dependent crapshoot (in fact, if you want to read more, googling for
"platform dependent crapshoot" works quite well...).
Are you interested in working on a patch? It's probably not straightforward
at all.
--
Comment By: Steven Bird (stevenbird)
Date: 2005-08-10 07:49
Message:
Logged In: YES
user_id=195736
Oh, I thought Python 2.4.1 was the same language, regardless
of which platform it was running on. I must be missing
something here.
--
Comment By: Michael Hudson (mwh)
Date: 2005-08-10 07:35
Message:
Logged In: YES
user_id=6656
At most, this is a feature request (why did you think it would work?).
Floating point to string (and vice versa) conversions are done by the C
library implementation, and sadly they are no consistent (you'll notice that
printing an infinite value on windows doesn't print out 'inf' either).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1255395&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1250389 ] The -m option to python does not search zip files
Bugs item #1250389, was opened at 2005-08-02 17:55 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250389&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: The -m option to python does not search zip files Initial Comment: The -m option, to run a module from sys.path as a main program, does not work when the module is in a zip file. Here is an example demonstrating: D:\Data>type zipmtest.py def a(): print "Hello, world" if __name__ == '__main__': a() D:\Data>python -m zipmtest Hello, world D:\Data>zip -9 zipm zipmtest.* adding: zipmtest.py (92 bytes security) (deflated 8%) D:\Data>set PYTHONPATH=zipm.zip D:\Data>del zipmtest.py Deleting D:\Data\zipmtest.py 1 file deleted D:\Data>python -m zipmtest python: module zipmtest not found D:\Data>python -c "import zipmtest" (note the last import - python can find the zipmtest module quite happily, but -m misses it). This is a fairly severe limitation on -m, particularly as use of "egg" distributions (which are basically zipfiles) becomes more common. -- >Comment By: Paul Moore (pmoore) Date: 2005-08-11 19:33 Message: Logged In: YES user_id=113328 I have looked into this, and it appears that _PyImportHooks_Init is getting called properly, and the zipimport mechanism is getting initialised (python -v -m a where a.py is in a zip file on sys.path shows this). The problem seems to be that main.c calls, in Py_Main, _PyImport_FindModule, with the "loader" argument set to NULL, which disables handling of PEP 302 style import hooks. This makes sense, to the extent that the current code needs a real FILE* to call PyRun_AnyFileExFlags, it should be possible (by calling PyRun_SimpleStringFlags instead, maybe?) to execute a module loaded from a hook. Unfortunately, I can't take this any further at present, as I don't have the means to build Python in order to test a patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250389&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1232947 ] non-admin install may fail (win xp pro)
Bugs item #1232947, was opened at 2005-07-05 20:31 Message generated for change (Comment added) made by pvrijlandt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232947&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Patrick Vrijlandt (pvrijlandt) Assigned to: Martin v. Löwis (loewis) Summary: non-admin install may fail (win xp pro) Initial Comment: concerns: python 2.4.1 msi When trying to do a non-admin install on Windows XP Pro, the installer probably tries to make shortcuts in a non-accessible directory. The status-window is displaying: creating shortcuts A messagebox appears and says the installer lacks priveliges on a certain directory: please try again as an administrator, (which i am obviously not). The cancel-option now leads to a rollback of the installation. -- >Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2005-08-11 21:11 Message: Logged In: YES user_id=1307917 These are difficult questions for me. I don't know if my ACL (access control list?) is on that folder. I'm almost certain the sysadmins did this for us. They try to get as much userfiles as possible on the network. They are also pretty restrictive (and understaffed) Backup is done only for network drives. The advantage is that I can access my user files from different computers (without using a server OS) My start menu is almost empty. All programs we are able to use, are accessible through a shortcut on the desktop. I probably can read the startmenu folder but not write it. "My documents" refers to a networked directory. I have full access there and can run programs from there. I suppose a patch would be to make more configuration options in the installer (Do you want to make shortcuts? Do you want to make them here?). I would make shortcuts on my desktop. (Yes, I can write there. Files sometimes go to c:\windows\desktop, and sometimes to a networked drive) What would be needed to run python (and pythonwin) from a memory-stick or cd-rom? If that would work, my problem would be solved too. Even better: one installation would make python accessible from any computer on our network I would login to. BTW: some drives (like C:) are hidden from explorer. I cannot do start -> run (but I can make a shortcut to cmd on my desktop, and run from there). I'm not sure I can get to regedit and/or do anything useful there. -- Comment By: Martin v. Löwis (loewis) Date: 2005-08-06 14:58 Message: Logged In: YES user_id=21627 According to the log file, there was an error accessing \bw2\snelkop\2003\info\programma's\Python 2.4 How come your Menu folder is on a network drive? What is the ACL on that folder? -- Comment By: Martin v. Löwis (loewis) Date: 2005-08-06 14:48 Message: Logged In: YES user_id=21627 Oops, missed the attachment. -- Comment By: Martin v. Löwis (loewis) Date: 2005-08-06 14:47 Message: Logged In: YES user_id=21627 Closed because of lack of response. -- Comment By: Martin v. Löwis (loewis) Date: 2005-07-06 07:16 Message: Logged In: YES user_id=21627 It works fine for me... Can you please install with msiexec /i python-2.4.1.msi /l*v python.log and attach a zipped version of python.log? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232947&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1232947 ] non-admin install may fail (win xp pro)
Bugs item #1232947, was opened at 2005-07-05 20:31 Message generated for change (Comment added) made by pvrijlandt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232947&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Patrick Vrijlandt (pvrijlandt) Assigned to: Martin v. Löwis (loewis) Summary: non-admin install may fail (win xp pro) Initial Comment: concerns: python 2.4.1 msi When trying to do a non-admin install on Windows XP Pro, the installer probably tries to make shortcuts in a non-accessible directory. The status-window is displaying: creating shortcuts A messagebox appears and says the installer lacks priveliges on a certain directory: please try again as an administrator, (which i am obviously not). The cancel-option now leads to a rollback of the installation. -- >Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2005-08-11 21:14 Message: Logged In: YES user_id=1307917 These are difficult questions for me. I don't know if my ACL (access control list?) is on that folder. I'm almost certain the sysadmins did this for us. They try to get as much userfiles as possible on the network. They are also pretty restrictive (and understaffed) Backup is done only for network drives. The advantage is that I can access my user files from different computers (without using a server OS) My start menu is almost empty. All programs we are able to use, are accessible through a shortcut on the desktop. I probably can read the startmenu folder but not write it. "My documents" refers to a networked directory. I have full access there and can run programs from there. I suppose a patch would be to make more configuration options in the installer (Do you want to make shortcuts? Do you want to make them here?). I would make shortcuts on my desktop. (Yes, I can write there. Files sometimes go to c:\windows\desktop, and sometimes to a networked drive) What would be needed to run python (and pythonwin) from a memory-stick or cd-rom? If that would work, my problem would be solved too. Even better: one installation would make python accessible from any computer on our network I would login to. BTW: some drives (like C:) are hidden from explorer. I cannot do start -> run (but I can make a shortcut to cmd on my desktop, and run from there). I'm not sure I can get to regedit and/or do anything useful there. -- Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2005-08-11 21:11 Message: Logged In: YES user_id=1307917 These are difficult questions for me. I don't know if my ACL (access control list?) is on that folder. I'm almost certain the sysadmins did this for us. They try to get as much userfiles as possible on the network. They are also pretty restrictive (and understaffed) Backup is done only for network drives. The advantage is that I can access my user files from different computers (without using a server OS) My start menu is almost empty. All programs we are able to use, are accessible through a shortcut on the desktop. I probably can read the startmenu folder but not write it. "My documents" refers to a networked directory. I have full access there and can run programs from there. I suppose a patch would be to make more configuration options in the installer (Do you want to make shortcuts? Do you want to make them here?). I would make shortcuts on my desktop. (Yes, I can write there. Files sometimes go to c:\windows\desktop, and sometimes to a networked drive) What would be needed to run python (and pythonwin) from a memory-stick or cd-rom? If that would work, my problem would be solved too. Even better: one installation would make python accessible from any computer on our network I would login to. BTW: some drives (like C:) are hidden from explorer. I cannot do start -> run (but I can make a shortcut to cmd on my desktop, and run from there). I'm not sure I can get to regedit and/or do anything useful there. -- Comment By: Martin v. Löwis (loewis) Date: 2005-08-06 14:58 Message: Logged In: YES user_id=21627 According to the log file, there was an error accessing \bw2\snelkop\2003\info\programma's\Python 2.4 How come your Menu folder is on a network drive? What is the ACL on that folder? -- Comment By: Martin v. Löwis (loewis) Date: 2005-08-06 14:48 Message: Logged In: YES user_id=21627 Oops, missed the attachment. -- Comment By: Martin v.
[ python-Bugs-1255218 ] "appropriately decorated" is undefined in MultiFile.push doc
Bugs item #1255218, was opened at 2005-08-09 14:07 Message generated for change (Comment added) made by aisaac0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1255218&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: "appropriately decorated" is undefined in MultiFile.push doc Initial Comment: At http://docs.python.org/lib/MultiFile-objects.html we read: push( str) Push a boundary string. When an appropriately decorated version of this boundary is found as an input line, it will be interpreted as a section-divider or end-marker. ... But this presumes that "appropriately decorated" is understood, which it won't be until multifile is understood. How about following that sentence with something like: (Appropriate decoration is determined by the section_divider and end_marker methods.) -- >Comment By: Alan (aisaac0) Date: 2005-08-11 15:58 Message: Logged In: YES user_id=1025672 IMO that works only if the term "appropriate decoration" occurs (appropriately) in those sections. And if it does, the relative location is probably irrelevant. This is really a problem of undefined terminology. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-08-11 12:11 Message: Logged In: YES user_id=593130 I agree that the sentence is confusing in its appropriate context. An alternative to the forward reference to the section_divider and end_marker methods is to move the entries for those methods just above the entry for the push method. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1255218&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1249749 ] Encodings and aliases do not match runtime
Bugs item #1249749, was opened at 2005-08-01 20:23
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249749&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: liturgist (liturgist)
Assigned to: Nobody/Anonymous (nobody)
Summary: Encodings and aliases do not match runtime
Initial Comment:
2.4.1 documentation has a list of standard encodings in
4.9.2. However, this list does not seem to match what
is returned by the runtime. Below is code to dump out
the encodings and aliases. Please tell me if anything
is incorrect.
In some cases, there are many more valid aliases than
listed in the documentation. See 'cp037' as an example.
I see that the identifiers are intended to be case
insensitive. I would prefer to see the documentation
provide the identifiers as they will appear in
encodings.aliases.aliases. The only alias containing
any upper case letters appears to be 'hp_roman8'.
$ cat encodingaliases.py
#!/usr/bin/env python
import sys
import encodings
def main():
enchash = {}
for enc in encodings.aliases.aliases.values():
enchash[enc] = []
for encalias in encodings.aliases.aliases.keys():
enchash[encodings.aliases.aliases[encalias]].append(encalias)
elist = enchash.keys()
elist.sort()
for enc in elist:
print enc, enchash[enc]
if __name__ == '__main__':
main()
sys.exit(0)
13:12 pwatson [
ruth.knightsbridge.com:/home/pwatson/src/python ] 366
$ ./encodingaliases.py
ascii ['iso_ir_6', 'ansi_x3_4_1968', 'ibm367',
'iso646_us', 'us', 'cp367', '646', 'us_ascii',
'csascii', 'ansi_x3.4_1986', 'iso_646.irv_1991',
'ansi_x3.4_1968']
base64_codec ['base_64', 'base64']
big5 ['csbig5', 'big5_tw']
big5hkscs ['hkscs', 'big5_hkscs']
bz2_codec ['bz2']
cp037 ['ebcdic_cp_wt', 'ebcdic_cp_us', 'ebcdic_cp_nl',
'037', 'ibm039', 'ibm037', 'csibm037', 'ebcdic_cp_ca']
cp1026 ['csibm1026', 'ibm1026', '1026']
cp1140 ['1140', 'ibm1140']
cp1250 ['1250', 'windows_1250']
cp1251 ['1251', 'windows_1251']
cp1252 ['windows_1252', '1252']
cp1253 ['1253', 'windows_1253']
cp1254 ['1254', 'windows_1254']
cp1255 ['1255', 'windows_1255']
cp1256 ['1256', 'windows_1256']
cp1257 ['1257', 'windows_1257']
cp1258 ['1258', 'windows_1258']
cp424 ['ebcdic_cp_he', 'ibm424', '424', 'csibm424']
cp437 ['ibm437', '437', 'cspc8codepage437']
cp500 ['csibm500', 'ibm500', '500', 'ebcdic_cp_ch',
'ebcdic_cp_be']
cp775 ['cspc775baltic', '775', 'ibm775']
cp850 ['ibm850', 'cspc850multilingual', '850']
cp852 ['ibm852', '852', 'cspcp852']
cp855 ['csibm855', 'ibm855', '855']
cp857 ['csibm857', 'ibm857', '857']
cp860 ['csibm860', 'ibm860', '860']
cp861 ['csibm861', 'cp_is', 'ibm861', '861']
cp862 ['cspc862latinhebrew', 'ibm862', '862']
cp863 ['csibm863', 'ibm863', '863']
cp864 ['csibm864', 'ibm864', '864']
cp865 ['csibm865', 'ibm865', '865']
cp866 ['csibm866', 'ibm866', '866']
cp869 ['csibm869', 'ibm869', '869', 'cp_gr']
cp932 ['mskanji', '932', 'ms932', 'ms_kanji']
cp949 ['uhc', 'ms949', '949']
cp950 ['ms950', '950']
euc_jis_2004 ['eucjis2004', 'jisx0213', 'euc_jis2004']
euc_jisx0213 ['eucjisx0213']
euc_jp ['eucjp', 'ujis', 'u_jis']
euc_kr ['ksc5601', 'korean', 'euckr', 'ksx1001',
'ks_c_5601', 'ks_c_5601_1987', 'ks_x_1001']
gb18030 ['gb18030_2000']
gb2312 ['chinese', 'euc_cn', 'csiso58gb231280',
'iso_ir_58', 'euccn', 'eucgb2312_cn', 'gb2312_1980',
'gb2312_80']
gbk ['cp936', 'ms936', '936']
hex_codec ['hex']
hp_roman8 ['csHPRoman8', 'r8', 'roman8']
hz ['hzgb', 'hz_gb_2312', 'hz_gb']
iso2022_jp ['iso2022jp', 'iso_2022_jp', 'csiso2022jp']
iso2022_jp_1 ['iso_2022_jp_1', 'iso2022jp_1']
iso2022_jp_2 ['iso_2022_jp_2', 'iso2022jp_2']
iso2022_jp_2004 ['iso_2022_jp_2004', 'iso2022jp_2004']
iso2022_jp_3 ['iso_2022_jp_3', 'iso2022jp_3']
iso2022_jp_ext ['iso2022jp_ext', 'iso_2022_jp_ext']
iso2022_kr ['iso_2022_kr', 'iso2022kr', 'csiso2022kr']
iso8859_10 ['csisolatin6', 'l6', 'iso_8859_10_1992',
'iso_ir_157', 'iso_8859_10', 'latin6']
iso8859_11 ['iso_8859_11', 'thai', 'iso_8859_11_2001']
iso8859_13 ['iso_8859_13']
iso8859_14 ['iso_celtic', 'iso_ir_199', 'l8',
'iso_8859_14_1998', 'iso_8859_14', 'latin8']
iso8859_15 ['iso_8859_15']
iso8859_16 ['iso_8859_16_2001', 'l10', 'iso_ir_226',
'latin10', 'iso_8859_16']
iso8859_2 ['l2', 'csisolatin2', 'iso_ir_101',
'iso_8859_2', 'iso_8859_2_1987', 'latin2']
iso8859_3 ['iso_8859_3_1988', 'l3', 'iso_ir_109',
'csisolatin3', 'iso_8859_3', 'latin3']
iso8859_4 ['csisolatin4', 'l4', 'iso_ir_110',
'iso_8859_4', 'iso_8859_4_1988', 'latin4']
iso8859_5 ['iso_8859_5_1988', 'iso_8859_5', 'cyrillic',
'csisolatincyrillic', 'iso_ir_144']
iso8859_6 ['iso_8859_6_1987', 'iso_ir_127',
'csisolatinarabic', 'asmo_708', 'iso_8859_6',
'ecma_114', 'arabic']
iso8859_7 ['ecma_118', 'greek8', 'is
[ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1
Bugs item #1178484, was opened at 2005-04-07 14:33
Message generated for change (Settings changed) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: Accepted
>Priority: 7
Submitted By: Timo Linna (tilinna)
Assigned to: Martin v. Löwis (loewis)
Summary: Erroneous line number error in Py2.4.1
Initial Comment:
For some reason Python 2.3.5 reports the error in the
following program correctly:
File "C:\Temp\problem.py", line 7
SyntaxError: unknown decode error
..whereas Python 2.4.1 reports an invalid line number:
File "C:\Temp\problem.py", line 2
SyntaxError: unknown decode error
- problem.py starts -
# -*- coding: ascii -*-
"""
Foo bar
"""
# Ä is not allowed in ascii coding
- problem.py ends -
Without the encoding declaration both Python versions
report the usual deprecation warning (just like they
should be doing).
My environment: Windows 2000 + SP3.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-08-11 17:22
Message:
Logged In: YES
user_id=1188172
Would it be appropriate to raise priority, then, to ensure
this doesn't get overlooked before 2.4.2?
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-08-11 16:04
Message:
Logged In: YES
user_id=89016
Somehow I forgot to upload the patch. Here it is
(diff2.txt). I'd like this patch to go into 2.4.2.
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-05-19 21:06
Message:
Logged In: YES
user_id=89016
> Walter, as I've said before: I know that you need buffering
> for the UTF-x readline support, but I don't see a
> requirement for it in most of the other codecs
The *charbuffer* is required for readline support, but the
*bytebuffer* is required for any non-charmap codec.
To have different buffering modes we'd either need a flag in
the StreamReader or use different classes, i.e. a class
hierarchy like the following:
StreamReader
UnbufferedStreamReader
CharmapStreamReader
ascii.StreamReader
iso_8859_1.StreamReader
BufferedStreamReader
utf_8.StreamReader
I don't think that we should introduce such a big change in
2.4.x. Furthermore there is another problem: The 2.4
buffering code automatically gives us universal newline
support. If you have a file foo.txt containing "a\rb", with
Python 2.4 you get:
>>> list(codecs.open("foo.txt", "rb", "latin-1"))
[u'a\r', u'b']
But with Python 2.3 you get:
>>> list(codecs.open("foo.txt", "rb", "latin-1"))
[u'a\rb']
If we would switch to the old StreamReader for the charmap
codecs, suddenly the stream reader for e.g. latin-1 and
UTF-8 would behave differently. Of course we could change
the buffering stream reader to only split lines on "\n", but
this would change functionality again.
> Your argument about applications making implications on the
> file position after having used .readline() is true, but
> still many applications rely on this behavior which is not
> as far fetched as it may seem given that they normally only
> expect 8-bit data.
If an application doesn't mix calls to read() with calls to
readline() (or different size values in these calls), the
change in behaviour from 2.3 to 2.4 shouldn't be this big.
No matter what we decide for the codecs, the tokenizer is
broken and should be fixed.
> Wouldn't it make things a lot safer if we only use buffering
> per default in the UTF-x codecs and revert back to the old
> non-buffered behavior for the other codecs which has worked
> well in the past ?!
Only if we'd drop the additional functionality added in 2.4.
(universal
newline support, the chars argument for read() and the
keepends argument for readline().), which I think could only
be done for 2.5.
> About your patch:
>
> * Please explain what firstline is supposed to do
> (preferably in the doc-string).
OK, I've added an explanation in the docstring.
> * Why is firstline always set in .readline() ?
firstline is only supposed to be used by readline(). We could
rename the argument to _firstline to make it clear that this is
a private parameter, or introduce a new method _read() that
has a firstline parameter. Then read() calls _read() with
firstline==False and readline() calls _read() with
firstline==True.
The purpose of firstline is to make sure that if an input
stream has
its first decoding error in line n, that the
UnicodeDecodeError will only be raised by the n'th call to
readline().
> * Please remove the print repr()
OK, done.
> * You cannot always be sure that exc has a .start attr
[ python-Bugs-1208304 ] urllib2's urlopen() method causes a memory leak
Bugs item #1208304, was opened at 2005-05-25 02:20
Message generated for change (Comment added) made by bwelling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1208304&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Petr Toman (manekcz)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2's urlopen() method causes a memory leak
Initial Comment:
It seems that the urlopen(url) methd of the urllib2 module
leaves some undestroyable objects in memory.
Please try the following code:
==
if __name__ == '__main__':
import urllib2
a = urllib2.urlopen('http://www.google.com')
del a # or a = None or del(a)
# check memory on memory leaks
import gc
gc.set_debug(gc.DEBUG_SAVEALL)
gc.collect()
for it in gc.garbage:
print it
==
In our code, we're using lots of urlopens in a loop and
the number of unreachable objects grows beyond all
limits :) We also tried a.close() but it didn't help.
You can also try the following:
==
def print_unreachable_len():
# check memory on memory leaks
import gc
gc.set_debug(gc.DEBUG_SAVEALL)
gc.collect()
unreachableL = []
for it in gc.garbage:
unreachableL.append(it)
return len(str(unreachableL))
if __name__ == '__main__':
print "at the beginning", print_unreachable_len()
import urllib2
print "after import of urllib2", print_unreachable_len()
a = urllib2.urlopen('http://www.google.com')
print 'after urllib2.urlopen', print_unreachable_len()
del a
print 'after del', print_unreachable_len()
==
We're using WindowsXP with latest patches, Python 2.4
(ActivePython 2.4 Build 243 (ActiveState Corp.) based on
Python 2.4 (#60, Nov 30 2004, 09:34:21) [MSC v.1310
32 bit (Intel)] on win32).
--
Comment By: Brian Wellington (bwelling)
Date: 2005-08-11 19:22
Message:
Logged In: YES
user_id=63197
We just ran into this same problem, and worked around it by
simply removing the 'r.recv = r.read' line in urllib2.py,
and creating a recv alias to the read function in
HTTPResponse ('recv = read' in the class).
Not sure if this is the best solution, but it seems to work.
--
Comment By: Sean Reifschneider (jafo)
Date: 2005-06-28 20:52
Message:
Logged In: YES
user_id=81797
I give up, this code is kind of a maze of twisty little
passages. I did try doing "a.fp.close()" and that didn't
seem to help at all. Couldn't really make any progress on
that though. I also tried doing a "if a.headers.fp:
a.headers.fp.close()", which didn't do anything noticable.
--
Comment By: Sean Reifschneider (jafo)
Date: 2005-06-28 20:27
Message:
Logged In: YES
user_id=81797
I can reproduce this in both the python.org 2.4 RPM and in a
freshly built copy from CVS. If I run a few thousand
urlopen()s, I get:
Traceback (most recent call last):
File "/tmp/mt", line 26, in ?
File "/tmp/python/dist/src/Lib/urllib2.py", line 130, in
urlopen
File "/tmp/python/dist/src/Lib/urllib2.py", line 361, in open
File "/tmp/python/dist/src/Lib/urllib2.py", line 379, in _open
File "/tmp/python/dist/src/Lib/urllib2.py", line 340, in
_call_chain
File "/tmp/python/dist/src/Lib/urllib2.py", line 1026, in
http_open
File "/tmp/python/dist/src/Lib/urllib2.py", line 1001, in
do_open
urllib2.URLError:
Even if I do a a.close(). I'll investigate a bit further.
Sean
--
Comment By: A.M. Kuchling (akuchling)
Date: 2005-06-01 16:13
Message:
Logged In: YES
user_id=11375
Confirmed. The objects involved seem to be an HTTPResponse and the
socket._fileobject wrapper; the assignment 'r.recv=r.read' around line 1013
of urllib2.py seems to be critical to creating the cycle.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1208304&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1257255 ] tarfile local name is local, should be abspath
Bugs item #1257255, was opened at 2005-08-12 02:26 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=1257255&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Martin Blais (blais) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile local name is local, should be abspath Initial Comment: I ran into a bug using the tarfile module with compression from a directory that did not exist anymore, and this exhibits a bug in the tarfile module. I'm not completely sure how to fix it with certainty, so instead of filing a quick patch, I submit a bug so people familiar with the module can have a look first. The problem is that when you open a tarfile with gz or bz2 compression, the TarFile object is opened with a filename that is not absolute, just local (basename is called) but the actual file is using a file-like object. Now, when you add a new entry, there is a check in the TarFile.add method that checks if we're not adding the archive itself into the tarfile, and this method calls abspath. Calling abspath on the name that has been basename'd is incorrect and a bug. It happens not to fail nor cause any problems when called from an existing directory (the test returns false), but it does not do the job it is supposed to. When the CWD has been deleted, calling abspath fails with an OSError, which brings out the problem. Some code to reproduce the bug is provided in an attachment. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257255&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
