From noreply at sourceforge.net Mon Aug 1 04:25:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 31 Jul 2005 19:25:41 -0700 Subject: [ python-Bugs-1248119 ] pdb 'next' does not skip list comprehension Message-ID: Bugs item #1248119, was opened at 2005-07-31 09:12 Message generated for change (Comment added) made by pepster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&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: Joseph Heled (pepster) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'next' does not skip list comprehension Initial Comment: pdb next command forces you to step over each list element. This seem to be a reincarnation of this old bug. https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523995&group_id=5470 Version: Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 ---------------------------------------------------------------------- >Comment By: Joseph Heled (pepster) Date: 2005-08-01 14:25 Message: Logged In: YES user_id=86677 I think this will be wonderfull .... The only viable workaround now is to wrap the code in a temporary function (i.e. lambda : ...). ugly. -Thanks, JOseph ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-08-01 08:48 Message: Logged In: YES user_id=971153 > you would realize what a serious bummer this is. I agree: this is a definite inconvenience. But I don't see how it is different from having to step through any other loop. However, I think there is a way to solve both problems at once..See below > Giving a 'next N' is nice, but will not be a real solution. > Somethims it is not easy to know how many iterations there > are. And when they are nested etc. Actually, I did not mean "next N" to skip N iterations, what I meant to have 'next N' (or at least next 1) to skip next N lines of code. I.e stop only when line>=line_where_next_N_happened+N is reached... So it seems like we are talking about the same thing...Right? There are a couple of corner cases which would have to be handled, (e.g keeping track of the current frame, etc) Also "next N" would allow to easily skip over any loops (not just list comprehensions), which I think would be a useful feature... What do you think? ---------------------------------------------------------------------- Comment By: Joseph Heled (pepster) Date: 2005-07-31 18:02 Message: Logged In: YES user_id=86677 You probably never use pdb in a real program, otherwise you would realize what a serious bummer this is. Giving a 'next N' is nice, but will not be a real solution. Somethims it is not easy to know how many iterations there are. And when they are nested etc. If you are convinced this is the desired and reasonable behaviour for next (a point of view I don't share), at least have a different command to skip to the next line. I am sorry but I have no idea if this is easy or hard. Thanks, Joseph ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-31 15:20 Message: Logged In: YES user_id=971153 While this behaviour indeed feels like a bug I'm starting to think that it is not.. Observation1: 'step' should stop at every iteration of a list comprehension Observation2: the only difference between 'step' and 'next' is that 'step' steps into function calls (which is not the case here) So, it seems like 'next' should also stop at every iteration of a list comprehenstion. Ie current behaviour is not a bug... Would supporting a numeric argument for the 'next' command make sense? So that 'next 1' would mean "stop when actual line number increases by at least 1"... ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-31 12:59 Message: Logged In: YES user_id=971153 A bit more information. I looked into what happens in ceval.c and apparently the current behaviour is intentional.. Looks like this piece of code: else if (frame->f_lasti <= *instr_prev) { /* jumping back in the same line forces a trace event */ result = call_trace(func, obj, frame, PyTrace_LINE, Py_None); } in maybe_call_line_trace() is responsible for the extra "line" events.. Seems like this piece of code was added to fix bug #765624. in ceval.c:2.386 So, should this (1248119) bug be dealt with by skipping extra line events in bdb? Any thoughts? Or am I totally lost? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-31 12:33 Message: Logged In: YES user_id=971153 I changed bdb.py to print the kind of event it receives as well as as line numbers and here is a session which illustrates the bug... bagira:~/python/dist/src/bug-next1248119> cat t #../python y=[1,2,3,4] x=[ i+1 for i in y] print x bagira:~/python/dist/src/bug-next1248119> ../python -m pdb t event: call; line 1, file event: line; line 1, file event: call; line 2, file t event: line; line 2, file t > /home/ilya/python/dist/src/bug-next1248119/t(2)?() -> y=[1,2,3,4] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] So it appears that the interpreter generates "line" events for every iteration of the loop.. Would this be a bug in the interpreter (and not in pdb/bdb)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&group_id=5470 From noreply at sourceforge.net Mon Aug 1 15:56:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Aug 2005 06:56:51 -0700 Subject: [ python-Bugs-1249573 ] rfc822 module, bug in parsedate_tz Message-ID: Bugs item #1249573, was opened at 2005-08-01 15:56 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=1249573&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: nemesis (nemesis_xpn) Assigned to: Nobody/Anonymous (nobody) Summary: rfc822 module, bug in parsedate_tz Initial Comment: I found that the function parsedate_tz of the rfc822 module has a bug (or at least I think so). I found a usenet article (message-id: <2714d.q75200 at myg.winews.net>) that has this Date field: Date: Tue,26 Jul 2005 13:14:27 GMT +0200 It seems to be correct?, but parsedate_tz is not able to decode it, it is confused by the absence of a space after the ",". I studied the parsedate_tz code and the problem is on its third line: ... if not data: return None data = data.split() ... After the split I have: ['Tue,26', 'Jul', '2005', '13:14:27', 'GMT', '+0200'] but "Tue," and "26" should be separated. Of course parsedate_tz correctly decode the field if you add a space after the ",". A possible solution is to change the line n?863 of rfc822.py (data=data.split()) with this one: data=data.replace(",",", ").split() it solves the problem and should not affect the normal behaviour. ? and looking at rfc2822 par3.3 it should be correct, the space after the comma is not mandatory: date-time = [ day-of-week "," ] date FWS time [CFWS] day-of-week = ([FWS] day-name) / obs-day-of-week day-name = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" date = day month year ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249573&group_id=5470 From noreply at sourceforge.net Mon Aug 1 16:54:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Aug 2005 07:54:05 -0700 Subject: [ python-Bugs-1249615 ] isinstance() fails depending on how modules imported Message-ID: Bugs item #1249615, was opened at 2005-08-01 14:54 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=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: Open Resolution: None 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> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249615&group_id=5470 From noreply at sourceforge.net Mon Aug 1 20:23:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Aug 2005 11:23:30 -0700 Subject: [ python-Bugs-1249749 ] Encodings and aliases do not match runtime Message-ID: Bugs item #1249749, was opened at 2005-08-01 13:23 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=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', 'iso_8859_7', 'iso_ir_126', 'elot_928', 'iso_8859_7_1987', 'csisolatingreek', 'greek'] iso8859_8 ['iso_8859_8_1988', 'iso_ir_138', 'iso_8859_8', 'csisolatinhebrew', 'hebrew'] iso8859_9 ['l5', 'iso_8859_9_1989', 'iso_8859_9', 'csisolatin5', 'latin5', 'iso_ir_148'] johab ['cp1361', 'ms1361'] koi8_r ['cskoi8r'] latin_1 ['iso8859', 'csisolatin1', 'latin', 'l1', 'iso_ir_100', 'ibm819', 'cp819', 'iso_8859_1', 'latin1', 'iso_8859_1_1987', '8859'] mac_cyrillic ['maccyrillic'] mac_greek ['macgreek'] mac_iceland ['maciceland'] mac_latin2 ['maccentraleurope', 'maclatin2'] mac_roman ['macroman'] mac_turkish ['macturkish'] mbcs ['dbcs'] ptcp154 ['cp154', 'cyrillic-asian', 'csptcp154', 'pt154'] quopri_codec ['quopri', 'quoted_printable', 'quotedprintable'] rot_13 ['rot13'] shift_jis ['s_jis', 'sjis', 'shiftjis', 'csshiftjis'] shift_jis_2004 ['shiftjis2004', 's_jis_2004', 'sjis_2004'] shift_jisx0213 ['shiftjisx0213', 'sjisx0213', 's_jisx0213'] tactis ['tis260'] tis_620 ['tis620', 'tis_620_2529_1', 'tis_620_2529_0', 'iso_ir_166', 'tis_620_0'] utf_16 ['utf16', 'u16'] utf_16_be ['utf_16be', 'unicodebigunmarked'] utf_16_le ['utf_16le', 'unicodelittleunmarked'] utf_7 ['u7', 'utf7'] utf_8 ['u8', 'utf', 'utf8_ucs4', 'utf8_ucs2', 'utf8'] uu_codec ['uu'] zlib_codec ['zlib', 'zip'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249749&group_id=5470 From noreply at sourceforge.net Mon Aug 1 22:47:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Aug 2005 13:47:44 -0700 Subject: [ python-Bugs-1249837 ] container methods raise KeyError not IndexError Message-ID: Bugs item #1249837, was opened at 2005-08-01 13:47 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=1249837&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: Wilfredo Sanchez (wsanchez) Assigned to: Nobody/Anonymous (nobody) Summary: container methods raise KeyError not IndexError Initial Comment: See: http://www.python.org/doc/2.3.5/ref/sequence-types.html, which says, for example, that __getitem__(self, key) should raise an IndexError if key is not in the container. However, built-in dicts raise KeyError instead, and http:// www.python.org/doc/2.3.5/lib/module-exceptions.html#l2h-289 implies that this is the correct behavior. This appears to be incorrect in the current documentation as well as in the 2.3.5 docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249837&group_id=5470 From noreply at sourceforge.net Mon Aug 1 23:26:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Aug 2005 14:26:38 -0700 Subject: [ python-Bugs-1249867 ] numarray in debian python 2.4.1 Message-ID: Bugs item #1249867, was opened at 2005-08-01 14: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=1249867&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: None Status: Open Resolution: None Priority: 5 Submitted By: LovePanda (lovepanda) Assigned to: Nobody/Anonymous (nobody) Summary: numarray in debian python 2.4.1 Initial Comment: Hi there, I ran across this error when running a few lines of code in debian python, but this runs perfectly in windows python. Basically I created a dummy matrix called "gamma" (using kroneckerproduct in numarray) and printed out its mean. Here is the code: gamma = kroneckerproduct(ones((N, 1)),identity(T)) print gamma.mean() and Here is the error message: Traceback (most recent call last): File "vul_prov.py", line 149, in ? VLs = mv_prov(hhc, idyrisk, provid, 1) File "/home/meng/China/Extent/Data/Urban2002/Empirics/tmp/vulnerability.py", line 605, in mv_prov print gamma.mean() File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1137, in mean return self.sum()/(self.nelements()*1.0) File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1133, in sum return ufunc.add.reduce(ufunc.add.areduce(self, type=type).flat, type=type) IndexError: too many indices. Thank you for helping on this! Oh, btw, the version for python in both platforms is 2.4.1 Xiangyi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249867&group_id=5470 From noreply at sourceforge.net Mon Aug 1 23:38:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Aug 2005 14:38:43 -0700 Subject: [ python-Bugs-1249873 ] numarray in debian python 2.4.1 Message-ID: Bugs item #1249873, was opened at 2005-08-01 14:38 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=1249873&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: None Status: Open Resolution: None Priority: 5 Submitted By: LovePanda (lovepanda) Assigned to: Nobody/Anonymous (nobody) Summary: numarray in debian python 2.4.1 Initial Comment: Hi there, I ran across this error when running a few lines of code in debian python, but this runs perfectly in windows python. Basically I created a dummy matrix called "gamma" (using kroneckerproduct in numarray) and printed out its mean. Here is the code: gamma = kroneckerproduct(ones((N, 1)),identity(T)) print gamma.mean() and Here is the error message: Traceback (most recent call last): File "vul_prov.py", line 149, in ? VLs = mv_prov(hhc, idyrisk, provid, 1) File "/home/meng/China/Extent/Data/Urban2002/Empirics/tmp/vulnerability.py", line 605, in mv_prov print gamma.mean() File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1137, in mean return self.sum()/(self.nelements()*1.0) File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1133, in sum return ufunc.add.reduce(ufunc.add.areduce(self, type=type).flat, type=type) IndexError: too many indices. Thank you for helping on this! Oh, btw, the version for python in both platforms is 2.4.1 Xiangyi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249873&group_id=5470 From noreply at sourceforge.net Mon Aug 1 23:54:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Aug 2005 14:54:38 -0700 Subject: [ python-Bugs-1249837 ] container methods raise KeyError not IndexError Message-ID: Bugs item #1249837, was opened at 2005-08-01 15:47 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249837&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: Wilfredo Sanchez (wsanchez) >Assigned to: Raymond Hettinger (rhettinger) Summary: container methods raise KeyError not IndexError Initial Comment: See: http://www.python.org/doc/2.3.5/ref/sequence-types.html, which says, for example, that __getitem__(self, key) should raise an IndexError if key is not in the container. However, built-in dicts raise KeyError instead, and http:// www.python.org/doc/2.3.5/lib/module-exceptions.html#l2h-289 implies that this is the correct behavior. This appears to be incorrect in the current documentation as well as in the 2.3.5 docs. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-01 16:54 Message: Logged In: YES user_id=80475 Both the behavior and the docs are correct. However, the docs are not especially clear on this point. Will add a clarifying note that KeyError is the appropriate error for mapping types when the key is not found. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249837&group_id=5470 From noreply at sourceforge.net Tue Aug 2 01:05:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Aug 2005 16:05:00 -0700 Subject: [ python-Bugs-1249903 ] numarray in debian python 2.4.1 Message-ID: Bugs item #1249903, was opened at 2005-08-01 16:05 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=1249903&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: None Status: Open Resolution: None Priority: 5 Submitted By: LovePanda (lovepanda) Assigned to: Nobody/Anonymous (nobody) Summary: numarray in debian python 2.4.1 Initial Comment: Hi there, I ran across this error when running a few lines of code in debian python, but this runs perfectly in windows python. Basically I created a dummy matrix called "gamma" (using kroneckerproduct in numarray) and printed out its mean. Here is the code: gamma = kroneckerproduct(ones((N, 1)),identity(T)) print gamma.mean() and Here is the error message: Traceback (most recent call last): File "vul_prov.py", line 149, in ? VLs = mv_prov(hhc, idyrisk, provid, 1) File "/home/meng/China/Extent/Data/Urban2002/Empirics/tmp/vulnerability.py", line 605, in mv_prov print gamma.mean() File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1137, in mean return self.sum()/(self.nelements()*1.0) File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1133, in sum return ufunc.add.reduce(ufunc.add.areduce(self, type=type).flat, type=type) IndexError: too many indices. Thank you for helping on this! Oh, btw, the version for python in both platforms is 2.4.1 Xiangyi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249903&group_id=5470 From noreply at sourceforge.net Tue Aug 2 04:54:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Aug 2005 19:54:08 -0700 Subject: [ python-Bugs-1243553 ] pydoc on cgi.escape lacks info that are in www docs Message-ID: Bugs item #1243553, was opened at 2005-07-23 07:33 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243553&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: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Nikos Kouremenos (nkour) >Assigned to: Skip Montanaro (montanaro) Summary: pydoc on cgi.escape lacks info that are in www docs Initial Comment: WWW: escape( s[, quote]) Convert the characters "&", "<" and ">" in string s to HTML-safe sequences. Use this if you need to display text that might contain such characters in HTML. If the optional flag quote is true, the double-quote character (""") is also translated; this helps for inclusion in an HTML attribute value, as in . If the value to be quoted might include single- or double-quote characters, or both, consider using the quoteattr() function in the xml.sax.saxutils module instead. pydoc cgi.escape = escape(s, quote=None) Replace special characters '&', '<' and '>' by SGML entities. why? ;( moreover pydoc doesn't even say what quote is!! ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-08-01 21:54 Message: Logged In: YES user_id=44345 I expanded the cgi.escape docstring a bit (v 1.84). In general though, the online doc can't really be a complete substitute for the reference documentation. It should be treated more as a hint for usage. ---------------------------------------------------------------------- Comment By: Nikos Kouremenos (nkour) Date: 2005-07-24 08:20 Message: Logged In: YES user_id=865368 pterk, thank you ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-24 07:55 Message: Logged In: YES user_id=174455 The documentation from pydoc is generated from doc-strings in the python source. Not only does this limit what you can do with it (hence the need for more elaborate documentation), it is also reasonable that this documentation remains terse. You should consider it more as a quick reference in stead of full-on documentation. I have submitted a small patch (1243910) to include a comment in the doc-string about quote. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243553&group_id=5470 From noreply at sourceforge.net Tue Aug 2 05:53:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Aug 2005 20:53:17 -0700 Subject: [ python-Bugs-1249965 ] IDLE does not start. 2.4.1 Message-ID: Bugs item #1249965, was opened at 2005-08-01 23:53 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=1249965&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: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: codepyro (codepyro) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE does not start. 2.4.1 Initial Comment: Installed Python 2.4.1 on Windows XP SP 2 I shutoff my Sygate Firewall and Stopped the Windows Firewall/ICS service. I also shut off all Anti-Virus services. I ran IDLE, it fails to start. No errors or anything. It does not show up in task manager either. IDLE in 2.3.4 worked.(uninstalled before installing 2.4.1) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249965&group_id=5470 From noreply at sourceforge.net Tue Aug 2 06:18:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Aug 2005 21:18:11 -0700 Subject: [ python-Bugs-1249965 ] IDLE does not start. 2.4.1 Message-ID: Bugs item #1249965, was opened at 2005-08-01 23:53 Message generated for change (Comment added) made by codepyro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249965&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: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: codepyro (codepyro) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE does not start. 2.4.1 Initial Comment: Installed Python 2.4.1 on Windows XP SP 2 I shutoff my Sygate Firewall and Stopped the Windows Firewall/ICS service. I also shut off all Anti-Virus services. I ran IDLE, it fails to start. No errors or anything. It does not show up in task manager either. IDLE in 2.3.4 worked.(uninstalled before installing 2.4.1) ---------------------------------------------------------------------- >Comment By: codepyro (codepyro) Date: 2005-08-02 00:18 Message: Logged In: YES user_id=1120033 Someone Suggested (PYthon installed on D) d:\Python24\pythonw.exe "d:\Python24\Lib\idlelib\idle.pyw" -n -s I ran that..Start -> Run It didnt work 2.3.5 Works. 2.4.0 Doesnt work.(Same prob) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249965&group_id=5470 From noreply at sourceforge.net Tue Aug 2 09:08:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 02 Aug 2005 00:08:55 -0700 Subject: [ python-Bugs-1249965 ] IDLE does not start. 2.4.1 Message-ID: Bugs item #1249965, was opened at 2005-08-01 23:53 Message generated for change (Comment added) made by codepyro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249965&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: IDLE Group: Python 2.4 >Status: Closed Resolution: None >Priority: 1 Submitted By: codepyro (codepyro) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE does not start. 2.4.1 Initial Comment: Installed Python 2.4.1 on Windows XP SP 2 I shutoff my Sygate Firewall and Stopped the Windows Firewall/ICS service. I also shut off all Anti-Virus services. I ran IDLE, it fails to start. No errors or anything. It does not show up in task manager either. IDLE in 2.3.4 worked.(uninstalled before installing 2.4.1) ---------------------------------------------------------------------- >Comment By: codepyro (codepyro) Date: 2005-08-02 03:08 Message: Logged In: YES user_id=1120033 Had to delete all the paths in registry and sys environment. This fixed the problem. IDLE with 2.4.1 works now. ---------------------------------------------------------------------- Comment By: codepyro (codepyro) Date: 2005-08-02 00:18 Message: Logged In: YES user_id=1120033 Someone Suggested (PYthon installed on D) d:\Python24\pythonw.exe "d:\Python24\Lib\idlelib\idle.pyw" -n -s I ran that..Start -> Run It didnt work 2.3.5 Works. 2.4.0 Doesnt work.(Same prob) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249965&group_id=5470 From noreply at sourceforge.net Tue Aug 2 11:11:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 02 Aug 2005 02:11:18 -0700 Subject: [ python-Bugs-1249873 ] numarray in debian python 2.4.1 Message-ID: Bugs item #1249873, was opened at 2005-08-01 23:38 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249873&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: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: LovePanda (lovepanda) Assigned to: Nobody/Anonymous (nobody) Summary: numarray in debian python 2.4.1 Initial Comment: Hi there, I ran across this error when running a few lines of code in debian python, but this runs perfectly in windows python. Basically I created a dummy matrix called "gamma" (using kroneckerproduct in numarray) and printed out its mean. Here is the code: gamma = kroneckerproduct(ones((N, 1)),identity(T)) print gamma.mean() and Here is the error message: Traceback (most recent call last): File "vul_prov.py", line 149, in ? VLs = mv_prov(hhc, idyrisk, provid, 1) File "/home/meng/China/Extent/Data/Urban2002/Empirics/tmp/vulnerability.py", line 605, in mv_prov print gamma.mean() File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1137, in mean return self.sum()/(self.nelements()*1.0) File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1133, in sum return ufunc.add.reduce(ufunc.add.areduce(self, type=type).flat, type=type) IndexError: too many indices. Thank you for helping on this! Oh, btw, the version for python in both platforms is 2.4.1 Xiangyi ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-02 11:11 Message: Logged In: YES user_id=1188172 Duplicate of #1249903. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249873&group_id=5470 From noreply at sourceforge.net Tue Aug 2 11:11:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 02 Aug 2005 02:11:48 -0700 Subject: [ python-Bugs-1249867 ] numarray in debian python 2.4.1 Message-ID: Bugs item #1249867, was opened at 2005-08-01 23:26 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249867&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: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: LovePanda (lovepanda) Assigned to: Nobody/Anonymous (nobody) Summary: numarray in debian python 2.4.1 Initial Comment: Hi there, I ran across this error when running a few lines of code in debian python, but this runs perfectly in windows python. Basically I created a dummy matrix called "gamma" (using kroneckerproduct in numarray) and printed out its mean. Here is the code: gamma = kroneckerproduct(ones((N, 1)),identity(T)) print gamma.mean() and Here is the error message: Traceback (most recent call last): File "vul_prov.py", line 149, in ? VLs = mv_prov(hhc, idyrisk, provid, 1) File "/home/meng/China/Extent/Data/Urban2002/Empirics/tmp/vulnerability.py", line 605, in mv_prov print gamma.mean() File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1137, in mean return self.sum()/(self.nelements()*1.0) File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1133, in sum return ufunc.add.reduce(ufunc.add.areduce(self, type=type).flat, type=type) IndexError: too many indices. Thank you for helping on this! Oh, btw, the version for python in both platforms is 2.4.1 Xiangyi ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-02 11:11 Message: Logged In: YES user_id=1188172 Duplicate of #1249903. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249867&group_id=5470 From noreply at sourceforge.net Tue Aug 2 11:13:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 02 Aug 2005 02:13:39 -0700 Subject: [ python-Bugs-1249903 ] numarray in debian python 2.4.1 Message-ID: Bugs item #1249903, was opened at 2005-08-02 01:05 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249903&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: None Status: Open Resolution: None Priority: 5 Submitted By: LovePanda (lovepanda) Assigned to: Nobody/Anonymous (nobody) Summary: numarray in debian python 2.4.1 Initial Comment: Hi there, I ran across this error when running a few lines of code in debian python, but this runs perfectly in windows python. Basically I created a dummy matrix called "gamma" (using kroneckerproduct in numarray) and printed out its mean. Here is the code: gamma = kroneckerproduct(ones((N, 1)),identity(T)) print gamma.mean() and Here is the error message: Traceback (most recent call last): File "vul_prov.py", line 149, in ? VLs = mv_prov(hhc, idyrisk, provid, 1) File "/home/meng/China/Extent/Data/Urban2002/Empirics/tmp/vulnerability.py", line 605, in mv_prov print gamma.mean() File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1137, in mean return self.sum()/(self.nelements()*1.0) File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1133, in sum return ufunc.add.reduce(ufunc.add.areduce(self, type=type).flat, type=type) IndexError: too many indices. Thank you for helping on this! Oh, btw, the version for python in both platforms is 2.4.1 Xiangyi ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-02 11:13 Message: Logged In: YES user_id=1188172 What values do N and T have? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249903&group_id=5470 From noreply at sourceforge.net Tue Aug 2 11:19:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 02 Aug 2005 02:19:56 -0700 Subject: [ python-Bugs-1249615 ] isinstance() fails depending on how modules imported Message-ID: Bugs item #1249615, was opened at 2005-08-01 16:54 Message generated for change (Comment added) made by birkenfeld 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: Open Resolution: None 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: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-02 11:19 Message: Logged In: YES user_id=1188172 This has bitten me too at one time. When you import a module from a package starting from different sys.path entries, you will end up with two different modules in sys.modules. This seems to be intended behaviour, but I don't know enough about it to close this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249615&group_id=5470 From noreply at sourceforge.net Tue Aug 2 12:30:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 02 Aug 2005 03:30:33 -0700 Subject: [ python-Bugs-1243192 ] Incorrect documentation of re.UNICODE Message-ID: Bugs item #1243192, was opened at 2005-07-22 18:20 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243192&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.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: nhaldimann (nhaldimann) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Incorrect documentation of re.UNICODE Initial Comment: The effects of the re.UNICODE flag are incorrectly documented in the library reference. Currently it says (Section 4.2.3): U UNICODE Make \w, \W, \b, and \B dependent on the Unicode character properties database. New in version 2.0. But this flag in fact also affects \d, \D, \s, and \S at least since Python 2.1 (I have checked 2.1.3 on Linux, 2.2.3, 2.3.5 and 2.4 on OS X and the source of _sre.c makes this obvious). Proof: Python 2.4 (#1, Feb 13 2005, 18:29:12) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> not re.match(r"\d", u"\u0966") True >>> re.match(r"\d", u"\u0966", re.UNICODE) <_sre.SRE_Match object at 0x36ee20> >>> not re.match(r"\s", u"\u2001") True >>> re.match(r"\s", u"\u2001", re.UNICODE) <_sre.SRE_Match object at 0x36ee20> \u0966 is some Indian digit, \u2001 is an em space. I propose to change the docs to: U UNICODE Make \w, \W, \b, \B, \d, \D, \s, and \S dependent on the Unicode character properties database. New in version 2.0. Maybe the documentation of \d, \D, \s, and \S in section 2.4.1 of the library reference should also be adapted. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-02 12:30 Message: Logged In: YES user_id=1188172 Thanks! Committed as Doc/lib/libre.tex r1.114, r1.112.2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243192&group_id=5470 From noreply at sourceforge.net Tue Aug 2 14:17:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 02 Aug 2005 05:17:12 -0700 Subject: [ python-Bugs-1250170 ] gethostbyname(gethostname()) fails on misconfigured system Message-ID: Bugs item #1250170, was opened at 2005-08-02 12:17 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=1250170&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: None Status: Open Resolution: None Priority: 5 Submitted By: Tadeusz Andrzej Kadlubowski (tkadlubo) Assigned to: Nobody/Anonymous (nobody) Summary: gethostbyname(gethostname()) fails on misconfigured system Initial Comment: Hello, I downloaded python CVS tree, compiled it and ran tests. Two tests failed: urllib2 and mimetools. Both in the same fashion, when doing socket.gethostbyname(socket.gethostname()) (It is used in mimetools.py library in line 130 and in test_urllib2.py test unit in line 352.) In the interpreter it fails in the following way: >>> import socket >>> socket.gethostbyname(socket.gethostname()) Traceback (most recent call last): File "", line 1, in ? socket.gaierror: (-2, 'Name or service not known') The reason is that my hostname is bogus, no single DNS knows about it, and I don't see any reason to set up a DNS server on my box. Of course editing /etc/hosts and adding my hostname as an alias for 127.0.0.1 solves the problem. Anyway I don't see any particular reason why the library shouldn't handle such situation i.e. when there's no connection between hostname and IP address. What do you think about it? I can make a SF patch item to solve this issue if you like. I am quite sure adding try/catch will make it in both cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250170&group_id=5470 From noreply at sourceforge.net Tue Aug 2 15:00:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 02 Aug 2005 06:00:54 -0700 Subject: [ python-Bugs-1249615 ] isinstance() fails depending on how modules imported Message-ID: Bugs item #1249615, was opened at 2005-08-01 14:54 Message generated for change (Comment added) made by hgibson50 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: Open Resolution: None 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: Hugh Gibson (hgibson50) Date: 2005-08-02 13: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 clearly there may be subtle failure modes - for example, exception handling may use isinstance() internally to see if an exception is an instance of a given class. I've modified the code and added some more testing which shows clearly that it's not the class object itself which is the problem, but when you have a class method which accepts an instance of the class as a parameter. Any test of the class of that parameter will fail if the first instance is created in one module and the second instance is created in another module, and they import the class module differently. Note that it's not restricted to isinstance() - checking __class__ fails as well. Also, in both of the modules that import the class module, isinstance() checking succeeds. There is a false sense of security that isinstance() checking will be OK. Modifed code attached. Hugh ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-02 09:19 Message: Logged In: YES user_id=1188172 This has bitten me too at one time. When you import a module from a package starting from different sys.path entries, you will end up with two different modules in sys.modules. This seems to be intended behaviour, but I don't know enough about it to close this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249615&group_id=5470 From noreply at sourceforge.net Tue Aug 2 15:14:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 02 Aug 2005 06:14:34 -0700 Subject: [ python-Bugs-1249615 ] isinstance() fails depending on how modules imported Message-ID: Bugs item #1249615, was opened at 2005-08-01 16:54 Message generated for change (Comment added) made by doerwalter 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: Open Resolution: None 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: Walter D?rwald (doerwalter) Date: 2005-08-02 15: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 15: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 clearly there may be subtle failure modes - for example, exception handling may use isinstance() internally to see if an exception is an instance of a given class. I've modified the code and added some more testing which shows clearly that it's not the class object itself which is the problem, but when you have a class method which accepts an instance of the class as a parameter. Any test of the class of that parameter will fail if the first instance is created in one module and the second instance is created in another module, and they import the class module differently. Note that it's not restricted to isinstance() - checking __class__ fails as well. Also, in both of the modules that import the class module, isinstance() checking succeeds. There is a false sense of security that isinstance() checking will be OK. Modifed code attached. Hugh ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-02 11:19 Message: Logged In: YES user_id=1188172 This has bitten me too at one time. When you import a module from a package starting from different sys.path entries, you will end up with two different modules in sys.modules. This seems to be intended behaviour, but I don't know enough about it to close this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249615&group_id=5470 From noreply at sourceforge.net Tue Aug 2 17:01:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 02 Aug 2005 08:01:55 -0700 Subject: [ python-Bugs-1250306 ] incorrect description of range function Message-ID: Bugs item #1250306, was opened at 2005-08-02 08:01 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=1250306&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: None Status: Open Resolution: None Priority: 5 Submitted By: John Gleeson (jgleeson) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect description of range function Initial Comment: The description of the behavior of the range function http://www.python.org/doc/current/lib/built-in-funcs.html#l2h-56 for negative values of step appears to be incorrect: "if step is negative, the last element is the largest start + i * step greater than stop." This implies that the last element is 'start'. I think it should say 'smallest' instead of 'largest'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250306&group_id=5470 From noreply at sourceforge.net Tue Aug 2 18:55:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 02 Aug 2005 09:55:26 -0700 Subject: [ python-Bugs-1250389 ] The -m option to python does not search zip files Message-ID: Bugs item #1250389, was opened at 2005-08-02 17:55 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=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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250389&group_id=5470 From noreply at sourceforge.net Tue Aug 2 20:52:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 02 Aug 2005 11:52:55 -0700 Subject: [ python-Bugs-1250469 ] Tix: PanedWindow.panes nonfunctional Message-ID: Bugs item #1250469, was opened at 2005-08-02 13:52 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=1250469&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: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Majromax (majromax) Assigned to: Martin v. L?wis (loewis) Summary: Tix: PanedWindow.panes nonfunctional Initial Comment: Tix.PanedWindow.panes() is nonfunctional for any but single-letter pane names; the culprit is the following line of code from Tix.PanedWindow.panes: names = self.tk.call(self._w, 'panes') Since the Tk "panes" command returns a string, it is not iterated over properly. The fix is: names = self.tk.split(self.tk.call(self._w, 'panes')) Attached is error log from Python 2.4, Windows 2k. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250469&group_id=5470 From noreply at sourceforge.net Wed Aug 3 09:13:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Aug 2005 00:13:52 -0700 Subject: [ python-Bugs-1249903 ] numarray in debian python 2.4.1 Message-ID: Bugs item #1249903, was opened at 2005-08-02 01:05 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249903&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: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: LovePanda (lovepanda) Assigned to: Nobody/Anonymous (nobody) Summary: numarray in debian python 2.4.1 Initial Comment: Hi there, I ran across this error when running a few lines of code in debian python, but this runs perfectly in windows python. Basically I created a dummy matrix called "gamma" (using kroneckerproduct in numarray) and printed out its mean. Here is the code: gamma = kroneckerproduct(ones((N, 1)),identity(T)) print gamma.mean() and Here is the error message: Traceback (most recent call last): File "vul_prov.py", line 149, in ? VLs = mv_prov(hhc, idyrisk, provid, 1) File "/home/meng/China/Extent/Data/Urban2002/Empirics/tmp/vulnerability.py", line 605, in mv_prov print gamma.mean() File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1137, in mean return self.sum()/(self.nelements()*1.0) File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1133, in sum return ufunc.add.reduce(ufunc.add.areduce(self, type=type).flat, type=type) IndexError: too many indices. Thank you for helping on this! Oh, btw, the version for python in both platforms is 2.4.1 Xiangyi ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-03 09:13 Message: Logged In: YES user_id=1188172 According to discussion on python-list, this was numarray's fault. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-02 11:13 Message: Logged In: YES user_id=1188172 What values do N and T have? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249903&group_id=5470 From noreply at sourceforge.net Wed Aug 3 09:18:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Aug 2005 00:18:19 -0700 Subject: [ python-Bugs-1250306 ] incorrect description of range function Message-ID: Bugs item #1250306, was opened at 2005-08-02 17:01 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250306&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Gleeson (jgleeson) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: incorrect description of range function Initial Comment: The description of the behavior of the range function http://www.python.org/doc/current/lib/built-in-funcs.html#l2h-56 for negative values of step appears to be incorrect: "if step is negative, the last element is the largest start + i * step greater than stop." This implies that the last element is 'start'. I think it should say 'smallest' instead of 'largest'. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-03 09:18 Message: Logged In: YES user_id=1188172 Correct. Committed as Doc/lib/libfuncs.tex r1.186, r1.175.2.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250306&group_id=5470 From noreply at sourceforge.net Wed Aug 3 09:45:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Aug 2005 00:45:50 -0700 Subject: [ python-Bugs-1249615 ] isinstance() fails depending on how modules imported Message-ID: Bugs item #1249615, was opened at 2005-08-01 14:54 Message generated for change (Comment added) made by hgibson50 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: None 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: Hugh Gibson (hgibson50) Date: 2005-08-03 07: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 13: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 13: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 clearly there may be subtle failure modes - for example, exception handling may use isinstance() internally to see if an exception is an instance of a given class. I've modified the code and added some more testing which shows clearly that it's not the class object itself which is the problem, but when you have a class method which accepts an instance of the class as a parameter. Any test of the class of that parameter will fail if the first instance is created in one module and the second instance is created in another module, and they import the class module differently. Note that it's not restricted to isinstance() - checking __class__ fails as well. Also, in both of the modules that import the class module, isinstance() checking succeeds. There is a false sense of security that isinstance() checking will be OK. Modifed code attached. Hugh ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-02 09:19 Message: Logged In: YES user_id=1188172 This has bitten me too at one time. When you import a module from a package starting from different sys.path entries, you will end up with two different modules in sys.modules. This seems to be intended behaviour, but I don't know enough about it to close this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249615&group_id=5470 From noreply at sourceforge.net Wed Aug 3 10:16:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Aug 2005 01:16:05 -0700 Subject: [ python-Bugs-1247765 ] "new" not marked as deprecated in the docs Message-ID: Bugs item #1247765, was opened at 2005-07-29 23:37 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1247765&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: None Status: Open Resolution: None Priority: 5 Submitted By: J?rgen Hermann (jhermann) Assigned to: Nobody/Anonymous (nobody) Summary: "new" not marked as deprecated in the docs Initial Comment: While >>> help('new') shows the deprecation of this module starting with 2.3, the docs at http://www.python.org/doc/current/lib/module-new.html don't. Shouldn't they? ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-08-03 08:16 Message: Logged In: YES user_id=987664 The new module should not be deprecated yet; it is help("new") that should be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1247765&group_id=5470 From noreply at sourceforge.net Wed Aug 3 10:19:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Aug 2005 01:19:34 -0700 Subject: [ python-Bugs-1248127 ] set of pdb breakpoint fails Message-ID: Bugs item #1248127, was opened at 2005-07-30 21:29 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248127&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: Joseph Heled (pepster) Assigned to: Nobody/Anonymous (nobody) Summary: set of pdb breakpoint fails Initial Comment: I can't set any pdb breakpoint. I try the command, (Pdb) break a:847 Breakpoint 4 at /home/joseph/743/rod/a.py:847 I get the message, "pdbtrack: Traceback cue not found" The breakpoint is never activated. Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-08-03 08:19 Message: Logged In: YES user_id=987664 pdbtrack is not part of Python; it is part of python-mode for Emacs. This is not a Python bug and should be closed. If you need to submit another bug please do so with a testcase and transcript of Python running outside Emacs. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-31 20:22 Message: Logged In: YES user_id=971153 This does not seem like a bug in python. It might be a bug in emacs' python-mode.. (http://sourceforge.net/projects/python-mode/) However, even that is not clear.. C-cC-c in emacs runs py-execute-buffer which seems to make a copy of the current buffer and run python on that copy...Which would obviosly impact handling of filenames I think the mainstream way to run pdb under Emacs is the pdb-mode. (M-x pdb) My suggestion would be to close this bug. ---------------------------------------------------------------------- Comment By: Joseph Heled (pepster) Date: 2005-07-31 06:30 Message: Logged In: YES user_id=86677 I tried a simple example outside emacs and it worked. Here is how it fails in emacs - visit a python buffer Do C-cC-c (py-execute-buffer) run pdb.run("some code") Try to set a breakpoint - get the "pdbtrack: Traceback cue not found" , and breakpoint never executed. I am not sure if it is supposed to work or not. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-31 00:07 Message: Logged In: YES user_id=971153 Could you provide an example (if possible a small one)? There are many reasons why a breakpoint may not be reachable.. Also it seems like you are running pdb under emacs, is it correct? Can you reproduce the problem outside of emacs? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248127&group_id=5470 From noreply at sourceforge.net Wed Aug 3 10:51:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Aug 2005 01:51:21 -0700 Subject: [ python-Bugs-1247765 ] "new" not marked as deprecated in the docs Message-ID: Bugs item #1247765, was opened at 2005-07-30 01:37 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1247765&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: None Status: Open Resolution: None Priority: 5 Submitted By: J?rgen Hermann (jhermann) Assigned to: Nobody/Anonymous (nobody) Summary: "new" not marked as deprecated in the docs Initial Comment: While >>> help('new') shows the deprecation of this module starting with 2.3, the docs at http://www.python.org/doc/current/lib/module-new.html don't. Shouldn't they? ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-03 10:51 Message: Logged In: YES user_id=1188172 Shouldn't it be deprecated? Look at the code in new.py. The only thing I can say in favour of new is that new.instancemethod() is prettier and clearer than types.MethodType(). ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-08-03 10:16 Message: Logged In: YES user_id=987664 The new module should not be deprecated yet; it is help("new") that should be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1247765&group_id=5470 From noreply at sourceforge.net Wed Aug 3 10:53:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Aug 2005 01:53:25 -0700 Subject: [ python-Bugs-1248127 ] set of pdb breakpoint fails Message-ID: Bugs item #1248127, was opened at 2005-07-30 23:29 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248127&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: Closed >Resolution: Invalid Priority: 5 Submitted By: Joseph Heled (pepster) Assigned to: Nobody/Anonymous (nobody) Summary: set of pdb breakpoint fails Initial Comment: I can't set any pdb breakpoint. I try the command, (Pdb) break a:847 Breakpoint 4 at /home/joseph/743/rod/a.py:847 I get the message, "pdbtrack: Traceback cue not found" The breakpoint is never activated. Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-03 10:53 Message: Logged In: YES user_id=1188172 Closing as requested. ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-08-03 10:19 Message: Logged In: YES user_id=987664 pdbtrack is not part of Python; it is part of python-mode for Emacs. This is not a Python bug and should be closed. If you need to submit another bug please do so with a testcase and transcript of Python running outside Emacs. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-31 22:22 Message: Logged In: YES user_id=971153 This does not seem like a bug in python. It might be a bug in emacs' python-mode.. (http://sourceforge.net/projects/python-mode/) However, even that is not clear.. C-cC-c in emacs runs py-execute-buffer which seems to make a copy of the current buffer and run python on that copy...Which would obviosly impact handling of filenames I think the mainstream way to run pdb under Emacs is the pdb-mode. (M-x pdb) My suggestion would be to close this bug. ---------------------------------------------------------------------- Comment By: Joseph Heled (pepster) Date: 2005-07-31 08:30 Message: Logged In: YES user_id=86677 I tried a simple example outside emacs and it worked. Here is how it fails in emacs - visit a python buffer Do C-cC-c (py-execute-buffer) run pdb.run("some code") Try to set a breakpoint - get the "pdbtrack: Traceback cue not found" , and breakpoint never executed. I am not sure if it is supposed to work or not. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-31 02:07 Message: Logged In: YES user_id=971153 Could you provide an example (if possible a small one)? There are many reasons why a breakpoint may not be reachable.. Also it seems like you are running pdb under emacs, is it correct? Can you reproduce the problem outside of emacs? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248127&group_id=5470 From noreply at sourceforge.net Wed Aug 3 11:12:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Aug 2005 02:12:26 -0700 Subject: [ python-Bugs-1247765 ] "new" not marked as deprecated in the docs Message-ID: Bugs item #1247765, was opened at 2005-07-29 23:37 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1247765&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: None Status: Open Resolution: None Priority: 5 Submitted By: J?rgen Hermann (jhermann) Assigned to: Nobody/Anonymous (nobody) Summary: "new" not marked as deprecated in the docs Initial Comment: While >>> help('new') shows the deprecation of this module starting with 2.3, the docs at http://www.python.org/doc/current/lib/module-new.html don't. Shouldn't they? ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-08-03 09:12 Message: Logged In: YES user_id=987664 When searching Python-dev all I could find was discussion over the eventual deprecation of types. If you deprecate the types module you still need a way to access the five types exposed in new. new is not listed in PEP 4 (Deprecation of Standard Modules). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-03 08:51 Message: Logged In: YES user_id=1188172 Shouldn't it be deprecated? Look at the code in new.py. The only thing I can say in favour of new is that new.instancemethod() is prettier and clearer than types.MethodType(). ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-08-03 08:16 Message: Logged In: YES user_id=987664 The new module should not be deprecated yet; it is help("new") that should be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1247765&group_id=5470 From noreply at sourceforge.net Wed Aug 3 14:54:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Aug 2005 05:54:13 -0700 Subject: [ python-Bugs-1251026 ] cgitb gives wrong lineno inside try:..finally: Message-ID: Bugs item #1251026, was opened at 2005-08-03 12:54 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=1251026&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: None Status: Open Resolution: None Priority: 5 Submitted By: Rob W.W. Hooft (hooft) Assigned to: Nobody/Anonymous (nobody) Summary: cgitb gives wrong lineno inside try:..finally: Initial Comment: If an error occurs in a try: finally: block, the normal traceback prints the correct line number, but the cgitb module prints the error as if it occurred in the last line of the finally: block. Example code: ==================== import cgitb cgitb.enable() try: 0//0 finally: print "This is not where the exception occurred!" ===================== Traceback correctly reports the error in line 5, but cgitb reports line 7. I am using python-2.3.4 on Debian/Linux. Probable cause: the inspect module, in getframeinfo, uses the f_lineno attribute from the frame object. This is what is printed in the cgitb trace. The traceback module uses the tb_lineno object of the traceback object itself, which is correct. Workaround: I am now working around this by using tb.tb_lineno in inspect.getframeinfo if a traceback object was passed, and f.f_lineno if a frame object was passed. I do not have sufficient insight in the code to foresee any other problems with this fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251026&group_id=5470 From noreply at sourceforge.net Wed Aug 3 14:55:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Aug 2005 05:55:10 -0700 Subject: [ python-Bugs-1251026 ] cgitb gives wrong lineno inside try:..finally: Message-ID: Bugs item #1251026, was opened at 2005-08-03 12:54 Message generated for change (Settings changed) made by hooft You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251026&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: None Status: Open Resolution: None Priority: 5 Submitted By: Rob W.W. Hooft (hooft) Assigned to: Nobody/Anonymous (nobody) Summary: cgitb gives wrong lineno inside try:..finally: Initial Comment: If an error occurs in a try: finally: block, the normal traceback prints the correct line number, but the cgitb module prints the error as if it occurred in the last line of the finally: block. Example code: ==================== import cgitb cgitb.enable() try: 0//0 finally: print "This is not where the exception occurred!" ===================== Traceback correctly reports the error in line 5, but cgitb reports line 7. I am using python-2.3.4 on Debian/Linux. Probable cause: the inspect module, in getframeinfo, uses the f_lineno attribute from the frame object. This is what is printed in the cgitb trace. The traceback module uses the tb_lineno object of the traceback object itself, which is correct. Workaround: I am now working around this by using tb.tb_lineno in inspect.getframeinfo if a traceback object was passed, and f.f_lineno if a frame object was passed. I do not have sufficient insight in the code to foresee any other problems with this fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251026&group_id=5470 From noreply at sourceforge.net Wed Aug 3 20:40:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Aug 2005 11:40:17 -0700 Subject: [ python-Bugs-1066546 ] test_pwd fails on 64bit system (Opteron) Message-ID: Bugs item #1066546, was opened at 2004-11-15 04:34 Message generated for change (Comment added) made by cmobarry 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 (bhcompile at dolly.build.redhat.com) (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: Clark Mobarry (cmobarry) Date: 2005-08-03 14: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 (bhcompile at thor.perf.redhat.com) (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 04: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 17: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 03:43 Message: Logged In: YES user_id=358087 1. How do I find the largest user id? 2. It's 4294967294 3. Can't attach etc/password since it's a company machine (IT will kill me :-) However there is a similar line for nobody with 65534 The hardware is 4 CPU with 16GB of memory. OS is: Red Hat Enterprise Linux AS release 3 (Taroon Update 3) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-11-16 20:58 Message: Logged In: YES user_id=33168 I just tested this on an opteron and it ran ok, so this problem isn't necessarily opteron/64-bit specific. What is the largest user id on the system? What is the value of pw_uid that is causing a problem? Can you attach your /etc/passwd file? If so, you may want to change any user info. I have: nobody:x:65534:65534:nobody:/:/bin/false I tried adding another nobody with a larger uid, but did not have any problems with the test. This is on a gentoo system. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-11-15 04:36 Message: Logged In: YES user_id=358087 Ran with -v: $ ./python Lib/test/test_pwd.py -v test_errors (__main__.PwdTest) ... ok test_values (__main__.PwdTest) ... ERROR ====================================================================== ERROR: test_values (__main__.PwdTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "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 ---------------------------------------------------------------------- Ran 2 tests in 0.480s FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_pwd.py", line 92, in ? test_main() File "Lib/test/test_pwd.py", line 89, in test_main test_support.run_unittest(PwdTest) File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py", line 290, in run_unitt est run_suite(suite, testclass) File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470 From noreply at sourceforge.net Wed Aug 3 21:49:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Aug 2005 12:49:18 -0700 Subject: [ python-Bugs-1251300 ] Decoding with unicode_internal segfaults on UCS-4 builds Message-ID: Bugs item #1251300, was opened at 2005-08-03 21: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=1251300&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: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: nhaldimann (nhaldimann) Assigned to: M.-A. Lemburg (lemburg) Summary: Decoding with unicode_internal segfaults on UCS-4 builds Initial Comment: On UCS-4 builds, decoding a byte string with the unicode_internal codec doesn't correctly work for code points from 0x80000000 upwards and even segfaults. I have observed the same behaviour on 2.5 from CVS and 2.4.0 on OS X/PowerPC as well as on 2.3.5 on Linux/x86. Here's an example: Python 2.5a0 (#1, Aug 3 2005, 21:34:05) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> "\x7f\xff\xff\xff".decode("unicode_internal") u'\U7fffffff' >>> "\x80\x00\x00\x00".decode("unicode_internal") u'\x00' >>> "\x80\x00\x00\x01".decode("unicode_internal") u'\x01' >>> "\x81\x00\x00\x00".decode("unicode_internal") Segmentation fault On little endian architectures the byte strings must be reversed for the same effect. I'm not sure if I understand what's going on, but I guess there are 2 solution strategies: 1. Make unicode_internal work for any code point up to 0xFFFFFFFF. 2. Make unicode_internal raise a UnicodeDecodeError for anything above 0x10FFFF (== sys.maxunicode for UCS-4 builds). It seems like there are no unicode code points above 0x10FFFF, so the latter solution feels more correct to me, even though it might break backwards compatibility a tiny bit. The unicodeescape codec already does a similar thing: >>> u"\U00110000" UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&group_id=5470 From noreply at sourceforge.net Thu Aug 4 00:14:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Aug 2005 15:14:07 -0700 Subject: [ python-Bugs-1248997 ] 2.3.5 SRPM fails to build without tkinter installed Message-ID: Bugs item #1248997, was opened at 2005-07-31 16:04 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248997&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: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Laurie Harper (zodiac) Assigned to: Martin v. L?wis (loewis) Summary: 2.3.5 SRPM fails to build without tkinter installed Initial Comment: If tkinter isn't available, rpmbuild fails due to the presence of unpackages files in usr/lib/python-2.3/lib-tk. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-08-03 17:14 Message: Logged In: YES user_id=2772 I'd rather see the build-requires line of the spec file have the required -devel packages listed, than fix the spec file to detect whether they're available and possibly build a python with reduced capabilities. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248997&group_id=5470 From noreply at sourceforge.net Thu Aug 4 04:50:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Aug 2005 19:50:34 -0700 Subject: [ python-Bugs-1251528 ] smtplib and email.py Message-ID: Bugs item #1251528, was opened at 2005-08-03 22:50 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=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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251528&group_id=5470 From noreply at sourceforge.net Thu Aug 4 07:30:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Aug 2005 22:30:05 -0700 Subject: [ python-Bugs-1248997 ] 2.3.5 SRPM fails to build without tkinter installed Message-ID: Bugs item #1248997, was opened at 2005-07-31 23:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248997&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: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Laurie Harper (zodiac) Assigned to: Martin v. L?wis (loewis) Summary: 2.3.5 SRPM fails to build without tkinter installed Initial Comment: If tkinter isn't available, rpmbuild fails due to the presence of unpackages files in usr/lib/python-2.3/lib-tk. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-04 07:30 Message: Logged In: YES user_id=21627 Sounds good. Can you provide a patch? ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-08-04 00:14 Message: Logged In: YES user_id=2772 I'd rather see the build-requires line of the spec file have the required -devel packages listed, than fix the spec file to detect whether they're available and possibly build a python with reduced capabilities. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248997&group_id=5470 From noreply at sourceforge.net Thu Aug 4 08:56:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Aug 2005 23:56:04 -0700 Subject: [ python-Bugs-1163244 ] Syntax error on large file with MBCS encoding Message-ID: Bugs item #1163244, was opened at 2005-03-14 20:20 Message generated for change (Comment added) made by jkew You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&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: Tim N. van der Leeuw (tnleeuw) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax error on large file with MBCS encoding Initial Comment: Large files generated by make-py.py from the win32all extensions cannot be compiled by Python2.4.1rc1 - they give a syntax error. This is a regression from 2.3.5 (With Python2.4, the interpreter crashes. That is fixed now.) Removing the mbcs encoding line from the top of the file, compilation succeeds. File should be attached, as zip-file. Probably requires win32all extensions to be installed to be compiled / imported (generated using build 203 of the win32all extensions). ---------------------------------------------------------------------- Comment By: James Kew (jkew) Date: 2005-08-04 06:56 Message: Logged In: YES user_id=598066 Is pywin32 bug 1166627 relevant/related? ---------------------------------------------------------------------- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-07-21 10:38 Message: Logged In: YES user_id=750513 For what it's worth: I have two files (that I unfortunately cannot attach) which works fine on 2.3 that now on 2.4.1 produces spurious syntax errors when they have # -*- coding: ascii -*- if I change that to something that does not match the coding regex I do not get any syntax error (winxp) ---------------------------------------------------------------------- Comment By: Niki Spahiev (nikis) Date: 2005-06-02 16:11 Message: Logged In: YES user_id=27708 i have reproductable test case with encoding cp1251 file is 1594 bytes long, how to attach it? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-14 23:40 Message: Logged In: YES user_id=89016 Importing foo2.py on Linux (with the current CVS HEAD version of Python) gives me a segmentation fault with the following stacktrace: 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 880 classname = inst->in_class->cl_name; (gdb) bt #0 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 #1 0x08082235 in PyObject_Repr (v=0xb7c158bc) at Objects/object.c:308 #2 0x080f3ccd in err_input (err=0xbfffe000) at Python/pythonrun.c:1478 #3 0x080f3956 in PyParser_SimpleParseFileFlags (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257, flags=0) at Python/pythonrun.c:1348 #4 0x080f3982 in PyParser_SimpleParseFile (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257) at Python/pythonrun.c:1355 #5 0x080e6fef in parse_source_module (pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:761 #6 0x080e72db in load_source_module (name=0xbfffe9d0 "foo2", pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:885 #7 0x080e86b4 in load_module (name=0xbfffe9d0 "foo2", fp=0x818d6e0, buf=0xbfffe530 "foo2.py", type=1, loader=0x0) at Python/import.c:1656 #8 0x080e9d52 in import_submodule (mod=0x8145768, subname=0xbfffe9d0 "foo2", fullname=0xbfffe9d0 "foo2") at Python/import.c:2250 #9 0x080e9511 in load_next (mod=0x8145768, altmod=0x8145768, p_name=0xbfffedf0, buf=0xbfffe9d0 "foo2", p_buflen=0xbfffe9cc) at Python/import.c:2070 #10 0x080e8e5e in import_module_ex (name=0x0, globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1905 #11 0x080e914b in PyImport_ImportModuleEx (name=0xb7cd8824 "foo2", globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1946 #12 0x080b5c87 in builtin___import__ (self=0x0, args=0xb7d1e634) at Python/bltinmodule.c:45 #13 0x0811d32e in PyCFunction_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/methodobject.c:73 #14 0x0805d188 in PyObject_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/abstract.c:1757 #15 0x080ca79d in PyEval_CallObjectWithKeywords (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Python/ceval.c:3425 #16 0x080c6719 in PyEval_EvalFrame (f=0x816dd7c) at Python/ceval.c:2026 #17 0x080c8fdd in PyEval_EvalCodeEx (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736 #18 0x080bffb0 in PyEval_EvalCode (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94) at Python/ceval.c:490 #19 0x080f361d in run_node (n=0xb7d122d0, filename=0x8123ba3 "", globals=0xb7d62e94, locals=0xb7d62e94, flags=0xbffff584) at Python/pythonrun.c:1265 #20 0x080f1f58 in PyRun_InteractiveOneFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xbffff584) at Python/pythonrun.c:762 #21 0x080f1c93 in PyRun_InteractiveLoopFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xbffff584) at Python/pythonrun.c:695 #22 0x080f1af6 in PyRun_AnyFileExFlags (fp=0xb7e94720, filename=0x8123ba3 "", closeit=0, flags=0xbffff584) at Python/pythonrun.c:658 #23 0x08055e45 in Py_Main (argc=1, argv=0xbffff634) at Modules/main.c:484 #24 0x08055366 in main (argc=1, argv=0xbffff634) at Modules/python.c:23 The value object in err_input() (in the E_DECODE case) seems to be bogus (it gives me a refcount of -606348325). ---------------------------------------------------------------------- Comment By: Timo Linna (tilinna) Date: 2005-04-09 08:09 Message: Logged In: YES user_id=1074183 Seems that the connection to n*512 blocks is very likely, and it's not just MBCS-related. I managed to reproduce this with a file that contains an ascii-coding declaration, close-to-1024 bytes section, extra crlf and a comment which raises a SyntaxError in Py2.4.1. Could this be linked to the new codec buffering code? See: www.python.org/sf/1178484 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-03-21 13:34 Message: Logged In: YES user_id=539787 Could be irrelevant but... are the other block sizes close to n*512 (eg 1536 is 3*512) marks? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-21 12:11 Message: Logged In: YES user_id=14198 I believe this is a different bug than the recent "long-lines" errors (see below). I can reproduce this with a file that uses neither long lines, nor any pywin32 extensions (2.4 branch, trunk) A Python source file containing: -- start snippet -- # -*- coding: mbcs -*- <1532 characters of code or comments> x = {} -- end snippet -- Will yield a SyntaxError when attempting to import the module. Running the module as a script does not provoke the error. To reproduce, there must be exactly 1532 characters where specified (see the attached file for a demo). Adding or removing even a single character will prevent the error. It is possible to replace characters with any others, including valid code, and still see the error - however, the number of characters must remain the same .cr/lf pairs can also be replaced with any other 2 characters. There are other "block sizes" that will provoke the error, but this is the only one I have nailed. Apart from the "block" of 1532 characters, the coding line and the blank line before the dict assignment also appear critical. Unlike the other characters in the block, this last cr/lf pair can not be replaced with comments. I can't provoke the error with other encodings (note there are no encoded characters in the sample - it is trivial). To reproduce, save the attached file on Windows and execute: > python -c "import foo2" Traceback (most recent call last): File "", line 1, in ? File "foo2.py", line 24 x = {} ^ SyntaxError: invalid syntax Note that Python 2.3 and earlier all work. Also note that "python foo2.py" also works. The code is clearly valid. Haven't tried to repro on Linux (mbcs isn't available there, and I can't get a test case that doesn't use it) Other pointers/notes: pywin32 bug 1085454 is related to long-lines, by all accounts that underlying error has been fixed - I can't verify this as pywin32 no longer generates insanely long lines. I can confirm Python bugs 1101726/1089395 still crashes Python 2.3+. I believe all (including this) are discrete bugs. [foo2.py is my attachment - ya gotta love sourceforge :)] ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-03-20 10:28 Message: Logged In: YES user_id=539787 Useful pointers: in Python-dev, this has been characterised as related to pywin32 bug 1085454. Also related to www.python.org/sf/1101726 and www.python.org/sf/1089395. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 From noreply at sourceforge.net Thu Aug 4 09:18:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Aug 2005 00:18:36 -0700 Subject: [ python-Bugs-1251631 ] Python 2.4.1 crashes when importing the attached script Message-ID: Bugs item #1251631, was opened at 2005-08-04 09:18 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=1251631&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: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.1 crashes when importing the attached script Initial Comment: OS: WinXP Prog. ENG SP1 Python: 2.4.1 MSI installer downloaded from python.org Python crashes or rarely raises MemoryError or SyntaxError when trying to import/execute the script attached. The behaviour changes when some lines are modified, but mostly crashes the python process with a memory access violation. The python process used 4.2Mbytes of system memory when crashed. There were more than 500Mbytes free. Register dump: EAX = 00A8CC61 EBX = 0000000A ECX = 00000000 EDX = 00000000 ESI = 00A10DA0 EDI = 00000022 EIP = 1E0A7F10 ESP = 0021FD98 EBP = 00000222 EFlags = 00000293 Other registers are irrelevant. The bug occured at the last line of the following instruction sequence because ECX was zero: 1E0A7EB2 66 C7 02 0A 00 mov word ptr [edx],0Ah 1E0A7EB7 8B 46 08 mov eax,dword ptr [esi+8] 1E0A7EBA 6A 00 push 0 1E0A7EBC 50 push eax 1E0A7EBD FF 15 B4 31 0C 1E call dword ptr ds:[1E0C31B4h] 1E0A7EC3 89 46 08 mov dword ptr [esi+8],eax 1E0A7EC6 8A 48 FF mov cl,byte ptr [eax-1] 1E0A7EC9 83 C4 08 add esp,8 1E0A7ECC 80 F9 0A cmp cl,0Ah 1E0A7ECF 0F 85 72 FF FF FF jne 1E0A7E47 1E0A7ED5 BB 0A 00 00 00 mov ebx,0Ah 1E0A7EDA 8B 0E mov ecx,dword ptr [esi] 1E0A7EDC 8B 54 24 0C mov edx,dword ptr [esp+0Ch] 1E0A7EE0 8D 04 11 lea eax,[ecx+edx] 1E0A7EE3 89 46 04 mov dword ptr [esi+4],eax 1E0A7EE6 8B 46 08 mov eax,dword ptr [esi+8] 1E0A7EE9 83 E8 02 sub eax,2 1E0A7EEC 3B C1 cmp eax,ecx 1E0A7EEE 72 0F jb 1E0A7EFF 1E0A7EF0 80 38 0D cmp byte ptr [eax],0Dh 1E0A7EF3 75 0A jne 1E0A7EFF 1E0A7EF5 C6 00 0A mov byte ptr [eax],0Ah 1E0A7EF8 40 inc eax 1E0A7EF9 C6 00 00 mov byte ptr [eax],0 1E0A7EFC 89 46 08 mov dword ptr [esi+8],eax 1E0A7EFF 39 5E 14 cmp dword ptr [esi+14h],ebx 1E0A7F02 75 21 jne 1E0A7F25 1E0A7F04 8B 4E 04 mov ecx,dword ptr [esi+4] 1E0A7F07 3B 4E 08 cmp ecx,dword ptr [esi+8] 1E0A7F0A 0F 84 24 FD FF FF je 1E0A7C34 1E0A7F10 0F B6 01 movzx eax,byte ptr [ecx] It may be possible to find the source line related to this bug by searching for this code in the retail python.exe then looking up the address in the map file produced by the compiler (if enabled). I can run the script with a debug version of python.exe. Please send me information about how to download a debug version for Windows. Note: I've tried to search this bug in the bug database, but it's not specific enough to find an exact match. No viruses nor spyware found on my machine using multiple antivirus/antispyware product. No memory errors found in 6 hours. I use LF (UNIX type) line ends on Windows to prevent errors when my scripts copied and edited on a Linux box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251631&group_id=5470 From noreply at sourceforge.net Thu Aug 4 09:21:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Aug 2005 00:21:56 -0700 Subject: [ python-Bugs-1251631 ] Python 2.4.1 crashes when importing the attached script Message-ID: Bugs item #1251631, was opened at 2005-08-04 09:18 Message generated for change (Comment added) made by complex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251631&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: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.1 crashes when importing the attached script Initial Comment: OS: WinXP Prog. ENG SP1 Python: 2.4.1 MSI installer downloaded from python.org Python crashes or rarely raises MemoryError or SyntaxError when trying to import/execute the script attached. The behaviour changes when some lines are modified, but mostly crashes the python process with a memory access violation. The python process used 4.2Mbytes of system memory when crashed. There were more than 500Mbytes free. Register dump: EAX = 00A8CC61 EBX = 0000000A ECX = 00000000 EDX = 00000000 ESI = 00A10DA0 EDI = 00000022 EIP = 1E0A7F10 ESP = 0021FD98 EBP = 00000222 EFlags = 00000293 Other registers are irrelevant. The bug occured at the last line of the following instruction sequence because ECX was zero: 1E0A7EB2 66 C7 02 0A 00 mov word ptr [edx],0Ah 1E0A7EB7 8B 46 08 mov eax,dword ptr [esi+8] 1E0A7EBA 6A 00 push 0 1E0A7EBC 50 push eax 1E0A7EBD FF 15 B4 31 0C 1E call dword ptr ds:[1E0C31B4h] 1E0A7EC3 89 46 08 mov dword ptr [esi+8],eax 1E0A7EC6 8A 48 FF mov cl,byte ptr [eax-1] 1E0A7EC9 83 C4 08 add esp,8 1E0A7ECC 80 F9 0A cmp cl,0Ah 1E0A7ECF 0F 85 72 FF FF FF jne 1E0A7E47 1E0A7ED5 BB 0A 00 00 00 mov ebx,0Ah 1E0A7EDA 8B 0E mov ecx,dword ptr [esi] 1E0A7EDC 8B 54 24 0C mov edx,dword ptr [esp+0Ch] 1E0A7EE0 8D 04 11 lea eax,[ecx+edx] 1E0A7EE3 89 46 04 mov dword ptr [esi+4],eax 1E0A7EE6 8B 46 08 mov eax,dword ptr [esi+8] 1E0A7EE9 83 E8 02 sub eax,2 1E0A7EEC 3B C1 cmp eax,ecx 1E0A7EEE 72 0F jb 1E0A7EFF 1E0A7EF0 80 38 0D cmp byte ptr [eax],0Dh 1E0A7EF3 75 0A jne 1E0A7EFF 1E0A7EF5 C6 00 0A mov byte ptr [eax],0Ah 1E0A7EF8 40 inc eax 1E0A7EF9 C6 00 00 mov byte ptr [eax],0 1E0A7EFC 89 46 08 mov dword ptr [esi+8],eax 1E0A7EFF 39 5E 14 cmp dword ptr [esi+14h],ebx 1E0A7F02 75 21 jne 1E0A7F25 1E0A7F04 8B 4E 04 mov ecx,dword ptr [esi+4] 1E0A7F07 3B 4E 08 cmp ecx,dword ptr [esi+8] 1E0A7F0A 0F 84 24 FD FF FF je 1E0A7C34 1E0A7F10 0F B6 01 movzx eax,byte ptr [ecx] It may be possible to find the source line related to this bug by searching for this code in the retail python.exe then looking up the address in the map file produced by the compiler (if enabled). I can run the script with a debug version of python.exe. Please send me information about how to download a debug version for Windows. Note: I've tried to search this bug in the bug database, but it's not specific enough to find an exact match. No viruses nor spyware found on my machine using multiple antivirus/antispyware product. No memory errors found in 6 hours. I use LF (UNIX type) line ends on Windows to prevent errors when my scripts copied and edited on a Linux box. ---------------------------------------------------------------------- >Comment By: Viktor Ferenczi (complex) Date: 2005-08-04 09:21 Message: Logged In: YES user_id=142612 The bug could be in python.dll, of course. I need a debug version of python.dll. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251631&group_id=5470 From noreply at sourceforge.net Thu Aug 4 09:50:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Aug 2005 00:50:28 -0700 Subject: [ python-Bugs-1163244 ] Syntax error on large file with MBCS encoding Message-ID: Bugs item #1163244, was opened at 2005-03-14 22:20 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&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: Tim N. van der Leeuw (tnleeuw) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax error on large file with MBCS encoding Initial Comment: Large files generated by make-py.py from the win32all extensions cannot be compiled by Python2.4.1rc1 - they give a syntax error. This is a regression from 2.3.5 (With Python2.4, the interpreter crashes. That is fixed now.) Removing the mbcs encoding line from the top of the file, compilation succeeds. File should be attached, as zip-file. Probably requires win32all extensions to be installed to be compiled / imported (generated using build 203 of the win32all extensions). ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-08-04 10:50 Message: Logged In: YES user_id=539787 Are you sure about the bug number? pywin32 seems not to have such a bug. ---------------------------------------------------------------------- Comment By: James Kew (jkew) Date: 2005-08-04 09:56 Message: Logged In: YES user_id=598066 Is pywin32 bug 1166627 relevant/related? ---------------------------------------------------------------------- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-07-21 13:38 Message: Logged In: YES user_id=750513 For what it's worth: I have two files (that I unfortunately cannot attach) which works fine on 2.3 that now on 2.4.1 produces spurious syntax errors when they have # -*- coding: ascii -*- if I change that to something that does not match the coding regex I do not get any syntax error (winxp) ---------------------------------------------------------------------- Comment By: Niki Spahiev (nikis) Date: 2005-06-02 19:11 Message: Logged In: YES user_id=27708 i have reproductable test case with encoding cp1251 file is 1594 bytes long, how to attach it? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-15 02:40 Message: Logged In: YES user_id=89016 Importing foo2.py on Linux (with the current CVS HEAD version of Python) gives me a segmentation fault with the following stacktrace: 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 880 classname = inst->in_class->cl_name; (gdb) bt #0 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 #1 0x08082235 in PyObject_Repr (v=0xb7c158bc) at Objects/object.c:308 #2 0x080f3ccd in err_input (err=0xbfffe000) at Python/pythonrun.c:1478 #3 0x080f3956 in PyParser_SimpleParseFileFlags (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257, flags=0) at Python/pythonrun.c:1348 #4 0x080f3982 in PyParser_SimpleParseFile (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257) at Python/pythonrun.c:1355 #5 0x080e6fef in parse_source_module (pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:761 #6 0x080e72db in load_source_module (name=0xbfffe9d0 "foo2", pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:885 #7 0x080e86b4 in load_module (name=0xbfffe9d0 "foo2", fp=0x818d6e0, buf=0xbfffe530 "foo2.py", type=1, loader=0x0) at Python/import.c:1656 #8 0x080e9d52 in import_submodule (mod=0x8145768, subname=0xbfffe9d0 "foo2", fullname=0xbfffe9d0 "foo2") at Python/import.c:2250 #9 0x080e9511 in load_next (mod=0x8145768, altmod=0x8145768, p_name=0xbfffedf0, buf=0xbfffe9d0 "foo2", p_buflen=0xbfffe9cc) at Python/import.c:2070 #10 0x080e8e5e in import_module_ex (name=0x0, globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1905 #11 0x080e914b in PyImport_ImportModuleEx (name=0xb7cd8824 "foo2", globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1946 #12 0x080b5c87 in builtin___import__ (self=0x0, args=0xb7d1e634) at Python/bltinmodule.c:45 #13 0x0811d32e in PyCFunction_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/methodobject.c:73 #14 0x0805d188 in PyObject_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/abstract.c:1757 #15 0x080ca79d in PyEval_CallObjectWithKeywords (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Python/ceval.c:3425 #16 0x080c6719 in PyEval_EvalFrame (f=0x816dd7c) at Python/ceval.c:2026 #17 0x080c8fdd in PyEval_EvalCodeEx (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736 #18 0x080bffb0 in PyEval_EvalCode (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94) at Python/ceval.c:490 #19 0x080f361d in run_node (n=0xb7d122d0, filename=0x8123ba3 "", globals=0xb7d62e94, locals=0xb7d62e94, flags=0xbffff584) at Python/pythonrun.c:1265 #20 0x080f1f58 in PyRun_InteractiveOneFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xbffff584) at Python/pythonrun.c:762 #21 0x080f1c93 in PyRun_InteractiveLoopFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xbffff584) at Python/pythonrun.c:695 #22 0x080f1af6 in PyRun_AnyFileExFlags (fp=0xb7e94720, filename=0x8123ba3 "", closeit=0, flags=0xbffff584) at Python/pythonrun.c:658 #23 0x08055e45 in Py_Main (argc=1, argv=0xbffff634) at Modules/main.c:484 #24 0x08055366 in main (argc=1, argv=0xbffff634) at Modules/python.c:23 The value object in err_input() (in the E_DECODE case) seems to be bogus (it gives me a refcount of -606348325). ---------------------------------------------------------------------- Comment By: Timo Linna (tilinna) Date: 2005-04-09 11:09 Message: Logged In: YES user_id=1074183 Seems that the connection to n*512 blocks is very likely, and it's not just MBCS-related. I managed to reproduce this with a file that contains an ascii-coding declaration, close-to-1024 bytes section, extra crlf and a comment which raises a SyntaxError in Py2.4.1. Could this be linked to the new codec buffering code? See: www.python.org/sf/1178484 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-03-21 15:34 Message: Logged In: YES user_id=539787 Could be irrelevant but... are the other block sizes close to n*512 (eg 1536 is 3*512) marks? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-21 14:11 Message: Logged In: YES user_id=14198 I believe this is a different bug than the recent "long-lines" errors (see below). I can reproduce this with a file that uses neither long lines, nor any pywin32 extensions (2.4 branch, trunk) A Python source file containing: -- start snippet -- # -*- coding: mbcs -*- <1532 characters of code or comments> x = {} -- end snippet -- Will yield a SyntaxError when attempting to import the module. Running the module as a script does not provoke the error. To reproduce, there must be exactly 1532 characters where specified (see the attached file for a demo). Adding or removing even a single character will prevent the error. It is possible to replace characters with any others, including valid code, and still see the error - however, the number of characters must remain the same .cr/lf pairs can also be replaced with any other 2 characters. There are other "block sizes" that will provoke the error, but this is the only one I have nailed. Apart from the "block" of 1532 characters, the coding line and the blank line before the dict assignment also appear critical. Unlike the other characters in the block, this last cr/lf pair can not be replaced with comments. I can't provoke the error with other encodings (note there are no encoded characters in the sample - it is trivial). To reproduce, save the attached file on Windows and execute: > python -c "import foo2" Traceback (most recent call last): File "", line 1, in ? File "foo2.py", line 24 x = {} ^ SyntaxError: invalid syntax Note that Python 2.3 and earlier all work. Also note that "python foo2.py" also works. The code is clearly valid. Haven't tried to repro on Linux (mbcs isn't available there, and I can't get a test case that doesn't use it) Other pointers/notes: pywin32 bug 1085454 is related to long-lines, by all accounts that underlying error has been fixed - I can't verify this as pywin32 no longer generates insanely long lines. I can confirm Python bugs 1101726/1089395 still crashes Python 2.3+. I believe all (including this) are discrete bugs. [foo2.py is my attachment - ya gotta love sourceforge :)] ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-03-20 12:28 Message: Logged In: YES user_id=539787 Useful pointers: in Python-dev, this has been characterised as related to pywin32 bug 1085454. Also related to www.python.org/sf/1101726 and www.python.org/sf/1089395. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 From noreply at sourceforge.net Thu Aug 4 16:11:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Aug 2005 07:11:17 -0700 Subject: [ python-Bugs-1251921 ] Fail codecs.lookup() on 'mbcs' and 'tactis' Message-ID: Bugs item #1251921, was opened at 2005-08-04 09:11 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=1251921&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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Fail codecs.lookup() on 'mbcs' and 'tactis' Initial Comment: $ python Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import codecs >>> codecs.lookup('ascii') (, , , ) >>> codecs.lookup('mbcs') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/encodings/__init__.py", line 96, in search_function globals(), locals(), _import_tail) File "/usr/lib/python2.4/encodings/mbcs.py", line 14, in ? class Codec(codecs.Codec): File "/usr/lib/python2.4/encodings/mbcs.py", line 18, in Codec encode = codecs.mbcs_encode AttributeError: 'module' object has no attribute 'mbcs_encode' >>> codecs.lookup('tactis') Traceback (most recent call last): File "", line 1, in ? LookupError: unknown encoding: tactis ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&group_id=5470 From noreply at sourceforge.net Thu Aug 4 16:38:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Aug 2005 07:38:31 -0700 Subject: [ python-Bugs-1251921 ] Fail codecs.lookup() on 'mbcs' and 'tactis' Message-ID: Bugs item #1251921, was opened at 2005-08-04 16:11 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Fail codecs.lookup() on 'mbcs' and 'tactis' Initial Comment: $ python Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import codecs >>> codecs.lookup('ascii') (, , , ) >>> codecs.lookup('mbcs') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/encodings/__init__.py", line 96, in search_function globals(), locals(), _import_tail) File "/usr/lib/python2.4/encodings/mbcs.py", line 14, in ? class Codec(codecs.Codec): File "/usr/lib/python2.4/encodings/mbcs.py", line 18, in Codec encode = codecs.mbcs_encode AttributeError: 'module' object has no attribute 'mbcs_encode' >>> codecs.lookup('tactis') Traceback (most recent call last): File "", line 1, in ? LookupError: unknown encoding: tactis ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:38 Message: Logged In: YES user_id=38388 mbcs is only available on Windows. I'm not sure what happened to the tactis codec - it's possible that it never got checked in. Do you have a reference for the tactis encoding ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&group_id=5470 From noreply at sourceforge.net Thu Aug 4 16:41:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Aug 2005 07:41:23 -0700 Subject: [ python-Bugs-1251300 ] Decoding with unicode_internal segfaults on UCS-4 builds Message-ID: Bugs item #1251300, was opened at 2005-08-03 21:49 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&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: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: nhaldimann (nhaldimann) Assigned to: M.-A. Lemburg (lemburg) Summary: Decoding with unicode_internal segfaults on UCS-4 builds Initial Comment: On UCS-4 builds, decoding a byte string with the unicode_internal codec doesn't correctly work for code points from 0x80000000 upwards and even segfaults. I have observed the same behaviour on 2.5 from CVS and 2.4.0 on OS X/PowerPC as well as on 2.3.5 on Linux/x86. Here's an example: Python 2.5a0 (#1, Aug 3 2005, 21:34:05) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> "\x7f\xff\xff\xff".decode("unicode_internal") u'\U7fffffff' >>> "\x80\x00\x00\x00".decode("unicode_internal") u'\x00' >>> "\x80\x00\x00\x01".decode("unicode_internal") u'\x01' >>> "\x81\x00\x00\x00".decode("unicode_internal") Segmentation fault On little endian architectures the byte strings must be reversed for the same effect. I'm not sure if I understand what's going on, but I guess there are 2 solution strategies: 1. Make unicode_internal work for any code point up to 0xFFFFFFFF. 2. Make unicode_internal raise a UnicodeDecodeError for anything above 0x10FFFF (== sys.maxunicode for UCS-4 builds). It seems like there are no unicode code points above 0x10FFFF, so the latter solution feels more correct to me, even though it might break backwards compatibility a tiny bit. The unicodeescape codec already does a similar thing: >>> u"\U00110000" UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:41 Message: Logged In: YES user_id=38388 I think solution 2 is the right approach, since UCS-4 only has 0x10FFFF possible code points. Could you provide a patch ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&group_id=5470 From noreply at sourceforge.net Thu Aug 4 16:47:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Aug 2005 07:47:22 -0700 Subject: [ python-Bugs-1249749 ] Encodings and aliases do not match runtime Message-ID: Bugs item #1249749, was opened at 2005-08-01 20:23 Message generated for change (Comment added) made by lemburg 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', 'iso_8859_7', 'iso_ir_126', 'elot_928', 'iso_8859_7_1987', 'csisolatingreek', 'greek'] iso8859_8 ['iso_8859_8_1988', 'iso_ir_138', 'iso_8859_8', 'csisolatinhebrew', 'hebrew'] iso8859_9 ['l5', 'iso_8859_9_1989', 'iso_8859_9', 'csisolatin5', 'latin5', 'iso_ir_148'] johab ['cp1361', 'ms1361'] koi8_r ['cskoi8r'] latin_1 ['iso8859', 'csisolatin1', 'latin', 'l1', 'iso_ir_100', 'ibm819', 'cp819', 'iso_8859_1', 'latin1', 'iso_8859_1_1987', '8859'] mac_cyrillic ['maccyrillic'] mac_greek ['macgreek'] mac_iceland ['maciceland'] mac_latin2 ['maccentraleurope', 'maclatin2'] mac_roman ['macroman'] mac_turkish ['macturkish'] mbcs ['dbcs'] ptcp154 ['cp154', 'cyrillic-asian', 'csptcp154', 'pt154'] quopri_codec ['quopri', 'quoted_printable', 'quotedprintable'] rot_13 ['rot13'] shift_jis ['s_jis', 'sjis', 'shiftjis', 'csshiftjis'] shift_jis_2004 ['shiftjis2004', 's_jis_2004', 'sjis_2004'] shift_jisx0213 ['shiftjisx0213', 'sjisx0213', 's_jisx0213'] tactis ['tis260'] tis_620 ['tis620', 'tis_620_2529_1', 'tis_620_2529_0', 'iso_ir_166', 'tis_620_0'] utf_16 ['utf16', 'u16'] utf_16_be ['utf_16be', 'unicodebigunmarked'] utf_16_le ['utf_16le', 'unicodelittleunmarked'] utf_7 ['u7', 'utf7'] utf_8 ['u8', 'utf', 'utf8_ucs4', 'utf8_ucs2', 'utf8'] uu_codec ['uu'] zlib_codec ['zlib', 'zip'] ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:47 Message: Logged In: YES user_id=38388 Doc patches are welcome - perhaps you could enhance your script to have the doc table generated from the available codecs and aliases ?! Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249749&group_id=5470 From noreply at sourceforge.net Thu Aug 4 16:55:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Aug 2005 07:55:50 -0700 Subject: [ python-Bugs-1251921 ] Fail codecs.lookup() on 'mbcs' and 'tactis' Message-ID: Bugs item #1251921, was opened at 2005-08-04 09:11 Message generated for change (Comment added) made by liturgist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Fail codecs.lookup() on 'mbcs' and 'tactis' Initial Comment: $ python Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import codecs >>> codecs.lookup('ascii') (, , , ) >>> codecs.lookup('mbcs') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/encodings/__init__.py", line 96, in search_function globals(), locals(), _import_tail) File "/usr/lib/python2.4/encodings/mbcs.py", line 14, in ? class Codec(codecs.Codec): File "/usr/lib/python2.4/encodings/mbcs.py", line 18, in Codec encode = codecs.mbcs_encode AttributeError: 'module' object has no attribute 'mbcs_encode' >>> codecs.lookup('tactis') Traceback (most recent call last): File "", line 1, in ? LookupError: unknown encoding: tactis ---------------------------------------------------------------------- >Comment By: liturgist (liturgist) Date: 2005-08-04 09:55 Message: Logged In: YES user_id=197677 UTF-8 is an MBCS encoding in that is is a "multiple byte character set", right? :-) UTF-16 is an MSCS; multiple short character set. There appears to have been some discussion on 'tactis' and 'tactis260' earlier in bug 854511. http://mail.python.org/pipermail/python-bugs-list/2003-December/021394.html ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 09:38 Message: Logged In: YES user_id=38388 mbcs is only available on Windows. I'm not sure what happened to the tactis codec - it's possible that it never got checked in. Do you have a reference for the tactis encoding ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&group_id=5470 From noreply at sourceforge.net Thu Aug 4 17:00:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Aug 2005 08:00:21 -0700 Subject: [ python-Bugs-1251921 ] Fail codecs.lookup() on 'mbcs' and 'tactis' Message-ID: Bugs item #1251921, was opened at 2005-08-04 09:11 Message generated for change (Comment added) made by liturgist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Fail codecs.lookup() on 'mbcs' and 'tactis' Initial Comment: $ python Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import codecs >>> codecs.lookup('ascii') (, , , ) >>> codecs.lookup('mbcs') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/encodings/__init__.py", line 96, in search_function globals(), locals(), _import_tail) File "/usr/lib/python2.4/encodings/mbcs.py", line 14, in ? class Codec(codecs.Codec): File "/usr/lib/python2.4/encodings/mbcs.py", line 18, in Codec encode = codecs.mbcs_encode AttributeError: 'module' object has no attribute 'mbcs_encode' >>> codecs.lookup('tactis') Traceback (most recent call last): File "", line 1, in ? LookupError: unknown encoding: tactis ---------------------------------------------------------------------- >Comment By: liturgist (liturgist) Date: 2005-08-04 10:00 Message: Logged In: YES user_id=197677 If 'mbcs' is Windows-only, then why does it appear in the list of registered codecs in encodings.aliases.aliases on the Linux platform? Shouldn't it not be registered on other platforms? ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-04 09:55 Message: Logged In: YES user_id=197677 UTF-8 is an MBCS encoding in that is is a "multiple byte character set", right? :-) UTF-16 is an MSCS; multiple short character set. There appears to have been some discussion on 'tactis' and 'tactis260' earlier in bug 854511. http://mail.python.org/pipermail/python-bugs-list/2003-December/021394.html ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 09:38 Message: Logged In: YES user_id=38388 mbcs is only available on Windows. I'm not sure what happened to the tactis codec - it's possible that it never got checked in. Do you have a reference for the tactis encoding ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&group_id=5470 From noreply at sourceforge.net Thu Aug 4 17:47:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Aug 2005 08:47:53 -0700 Subject: [ python-Bugs-1252001 ] Issue with telnetlib read_until not timing out Message-ID: Bugs item #1252001, was opened at 2005-08-04 11:47 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=1252001&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: padded (padded) Assigned to: Nobody/Anonymous (nobody) Summary: Issue with telnetlib read_until not timing out Initial Comment: So, I looked through the read_until code and there is no provision to jump out of the function and return whatever its got so far if it reaches the timeout. This is a problem and so far I couldn't see anyone giving people a clear reason why this is happening. So I added a few snippets of code to handle the timeout. So if you pass a timeout value along with the read_until, it will timeout after that many seconds (roughly). Here's my snippet of the code: def read_until(self, match, timeout=None): """Read until a given string is encountered or until timeout. When no match is found, return whatever is available instead, possibly the empty string. Raise EOFError if the connection is closed and no cooked data is available. Modified such that the timeout feature DOES timeout when it needs to. """ n = len(match) self.process_rawq() i = self.cookedq.find(match) if i >= 0: i = i+n buf = self.cookedq[:i] self.cookedq = self.cookedq[i:] return buf s_reply = ([self], [], []) s_args = s_reply if timeout is not None: s_args = s_args + (timeout,) timeoutcounter=0 #added this, simple counter for number of times we've slept while not self.eof and select.select(*s_args) == s_reply: i = max(0, len(self.cookedq)-n) self.fill_rawq() self.process_rawq() i = self.cookedq.find(match, i) if i >= 0: i = i+n buf = self.cookedq[:i] self.cookedq = self.cookedq[i:] return buf if timeout is not None:#this will handle the timeout. time.sleep(1) timeoutcounter+=1 if(timeoutcounter>timeout): buf=self.cookedq self.cookedq = "" return buf return self.read_very_lazy() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252001&group_id=5470 From noreply at sourceforge.net Thu Aug 4 17:52:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Aug 2005 08:52:22 -0700 Subject: [ python-Bugs-1252001 ] Issue with telnetlib read_until not timing out Message-ID: Bugs item #1252001, was opened at 2005-08-04 11:47 Message generated for change (Comment added) made by padded You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252001&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: padded (padded) Assigned to: Nobody/Anonymous (nobody) Summary: Issue with telnetlib read_until not timing out Initial Comment: So, I looked through the read_until code and there is no provision to jump out of the function and return whatever its got so far if it reaches the timeout. This is a problem and so far I couldn't see anyone giving people a clear reason why this is happening. So I added a few snippets of code to handle the timeout. So if you pass a timeout value along with the read_until, it will timeout after that many seconds (roughly). Here's my snippet of the code: def read_until(self, match, timeout=None): """Read until a given string is encountered or until timeout. When no match is found, return whatever is available instead, possibly the empty string. Raise EOFError if the connection is closed and no cooked data is available. Modified such that the timeout feature DOES timeout when it needs to. """ n = len(match) self.process_rawq() i = self.cookedq.find(match) if i >= 0: i = i+n buf = self.cookedq[:i] self.cookedq = self.cookedq[i:] return buf s_reply = ([self], [], []) s_args = s_reply if timeout is not None: s_args = s_args + (timeout,) timeoutcounter=0 #added this, simple counter for number of times we've slept while not self.eof and select.select(*s_args) == s_reply: i = max(0, len(self.cookedq)-n) self.fill_rawq() self.process_rawq() i = self.cookedq.find(match, i) if i >= 0: i = i+n buf = self.cookedq[:i] self.cookedq = self.cookedq[i:] return buf if timeout is not None:#this will handle the timeout. time.sleep(1) timeoutcounter+=1 if(timeoutcounter>timeout): buf=self.cookedq self.cookedq = "" return buf return self.read_very_lazy() ---------------------------------------------------------------------- >Comment By: padded (padded) Date: 2005-08-04 11:52 Message: Logged In: YES user_id=1324012 note that you need to import time for this to work ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252001&group_id=5470 From noreply at sourceforge.net Thu Aug 4 18:13:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Aug 2005 09:13:34 -0700 Subject: [ python-Bugs-1196154 ] Error: ... ossaudiodev.c, line 48: Missing type specifier Message-ID: Bugs item #1196154, was opened at 2005-05-05 19:53 Message generated for change (Comment added) made by diskman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196154&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: Build Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Will L G (diskman) Assigned to: Nobody/Anonymous (nobody) Summary: Error: ... ossaudiodev.c, line 48: Missing type specifier Initial Comment: RedHat Linux 7.2 [alpha] Kernel 2.6.11.6 Compaq C 6.5.2 Binutils 2.15 Make 2.8 Was receiving the error below and then a few little changes to make the configure script think I was using gcc while still using ccc... [root at jericho Python-2.4.1]# make case $MAKEFLAGS in *-s*) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py -q build;; *) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py build;; esac Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re ImportError: No module named os make: *** [sharedmods] Error 1 [root at jericho Python-2.4.1]# Here is a copy of the little script I used to set the env to use ccc while configuring python to compile using gcc and thus build the appropriate extensions: ./configure --prefix=/usr --sysconfdir=/etc --build=alphapca56-alpha-linux-gnu --without-gcc --enable-shared --with-dec-threads --with-cxx="ccache cxx" --with-cc="ccache ccc" --without-threads make CC="ccache ccc" CXX="ccache cxx" CFLAGS="-O5 -fast -mtune=ev56 -w -pipe - lpthread -threads" CXXFLAGS="-O5 -fast -mtune=ev56 -w -pipe - lpthread -threads" EVERYTHING compiled fine but for one little thing, two extensions didn't compile: building 'ossaudiodev' extension ccache ccc -DNDEBUG -O -fPIC -OPT:Olimit=0 -I. - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1/./Include -I/usr/local/include -I/usr2/www/pub/alpha- RH7/programming/python/Python-2.4.1/Include - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1 -c /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c -o build/temp.linux-alpha- 2.4/ossaudiodev.o cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 48: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 57: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ ccache ccc -DNDEBUG -O -fPIC -OPT:Olimit=0 -I. - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1/./Include -I/usr/local/include -I/usr2/www/pub/alpha- RH7/programming/python/Python-2.4.1/Include - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1 -c /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c -o build/temp.linux-alpha- 2.4/ossaudiodev.o cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 48: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 57: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ cc: Info: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/./Include/objimpl.h, line 255: In this declaration, type long double has the same representation as type double on this platform. (longdoublenyi) long double dummy; /* force worst-case alignment */ ---------------------------------------------------------------------- >Comment By: Will L G (diskman) Date: 2005-08-04 16:13 Message: Logged In: YES user_id=312992 I thought Python-2.4.1 was in 'bug fix' mode? Well this fucker is as OLD as dirt... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196154&group_id=5470 From noreply at sourceforge.net Thu Aug 4 19:10:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Aug 2005 10:10:28 -0700 Subject: [ python-Bugs-1163244 ] Syntax error on large file with MBCS encoding Message-ID: Bugs item #1163244, was opened at 2005-03-14 20:20 Message generated for change (Comment added) made by jkew You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&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: Tim N. van der Leeuw (tnleeuw) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax error on large file with MBCS encoding Initial Comment: Large files generated by make-py.py from the win32all extensions cannot be compiled by Python2.4.1rc1 - they give a syntax error. This is a regression from 2.3.5 (With Python2.4, the interpreter crashes. That is fixed now.) Removing the mbcs encoding line from the top of the file, compilation succeeds. File should be attached, as zip-file. Probably requires win32all extensions to be installed to be compiled / imported (generated using build 203 of the win32all extensions). ---------------------------------------------------------------------- Comment By: James Kew (jkew) Date: 2005-08-04 17:10 Message: Logged In: YES user_id=598066 http://sourceforge.net/tracker/? func=detail&aid=1166627&group_id=78018&atid=551954 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-08-04 07:50 Message: Logged In: YES user_id=539787 Are you sure about the bug number? pywin32 seems not to have such a bug. ---------------------------------------------------------------------- Comment By: James Kew (jkew) Date: 2005-08-04 06:56 Message: Logged In: YES user_id=598066 Is pywin32 bug 1166627 relevant/related? ---------------------------------------------------------------------- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-07-21 10:38 Message: Logged In: YES user_id=750513 For what it's worth: I have two files (that I unfortunately cannot attach) which works fine on 2.3 that now on 2.4.1 produces spurious syntax errors when they have # -*- coding: ascii -*- if I change that to something that does not match the coding regex I do not get any syntax error (winxp) ---------------------------------------------------------------------- Comment By: Niki Spahiev (nikis) Date: 2005-06-02 16:11 Message: Logged In: YES user_id=27708 i have reproductable test case with encoding cp1251 file is 1594 bytes long, how to attach it? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-14 23:40 Message: Logged In: YES user_id=89016 Importing foo2.py on Linux (with the current CVS HEAD version of Python) gives me a segmentation fault with the following stacktrace: 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 880 classname = inst->in_class->cl_name; (gdb) bt #0 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 #1 0x08082235 in PyObject_Repr (v=0xb7c158bc) at Objects/object.c:308 #2 0x080f3ccd in err_input (err=0xbfffe000) at Python/pythonrun.c:1478 #3 0x080f3956 in PyParser_SimpleParseFileFlags (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257, flags=0) at Python/pythonrun.c:1348 #4 0x080f3982 in PyParser_SimpleParseFile (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257) at Python/pythonrun.c:1355 #5 0x080e6fef in parse_source_module (pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:761 #6 0x080e72db in load_source_module (name=0xbfffe9d0 "foo2", pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:885 #7 0x080e86b4 in load_module (name=0xbfffe9d0 "foo2", fp=0x818d6e0, buf=0xbfffe530 "foo2.py", type=1, loader=0x0) at Python/import.c:1656 #8 0x080e9d52 in import_submodule (mod=0x8145768, subname=0xbfffe9d0 "foo2", fullname=0xbfffe9d0 "foo2") at Python/import.c:2250 #9 0x080e9511 in load_next (mod=0x8145768, altmod=0x8145768, p_name=0xbfffedf0, buf=0xbfffe9d0 "foo2", p_buflen=0xbfffe9cc) at Python/import.c:2070 #10 0x080e8e5e in import_module_ex (name=0x0, globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1905 #11 0x080e914b in PyImport_ImportModuleEx (name=0xb7cd8824 "foo2", globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1946 #12 0x080b5c87 in builtin___import__ (self=0x0, args=0xb7d1e634) at Python/bltinmodule.c:45 #13 0x0811d32e in PyCFunction_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/methodobject.c:73 #14 0x0805d188 in PyObject_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/abstract.c:1757 #15 0x080ca79d in PyEval_CallObjectWithKeywords (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Python/ceval.c:3425 #16 0x080c6719 in PyEval_EvalFrame (f=0x816dd7c) at Python/ceval.c:2026 #17 0x080c8fdd in PyEval_EvalCodeEx (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736 #18 0x080bffb0 in PyEval_EvalCode (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94) at Python/ceval.c:490 #19 0x080f361d in run_node (n=0xb7d122d0, filename=0x8123ba3 "", globals=0xb7d62e94, locals=0xb7d62e94, flags=0xbffff584) at Python/pythonrun.c:1265 #20 0x080f1f58 in PyRun_InteractiveOneFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xbffff584) at Python/pythonrun.c:762 #21 0x080f1c93 in PyRun_InteractiveLoopFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xbffff584) at Python/pythonrun.c:695 #22 0x080f1af6 in PyRun_AnyFileExFlags (fp=0xb7e94720, filename=0x8123ba3 "", closeit=0, flags=0xbffff584) at Python/pythonrun.c:658 #23 0x08055e45 in Py_Main (argc=1, argv=0xbffff634) at Modules/main.c:484 #24 0x08055366 in main (argc=1, argv=0xbffff634) at Modules/python.c:23 The value object in err_input() (in the E_DECODE case) seems to be bogus (it gives me a refcount of -606348325). ---------------------------------------------------------------------- Comment By: Timo Linna (tilinna) Date: 2005-04-09 08:09 Message: Logged In: YES user_id=1074183 Seems that the connection to n*512 blocks is very likely, and it's not just MBCS-related. I managed to reproduce this with a file that contains an ascii-coding declaration, close-to-1024 bytes section, extra crlf and a comment which raises a SyntaxError in Py2.4.1. Could this be linked to the new codec buffering code? See: www.python.org/sf/1178484 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-03-21 13:34 Message: Logged In: YES user_id=539787 Could be irrelevant but... are the other block sizes close to n*512 (eg 1536 is 3*512) marks? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-21 12:11 Message: Logged In: YES user_id=14198 I believe this is a different bug than the recent "long-lines" errors (see below). I can reproduce this with a file that uses neither long lines, nor any pywin32 extensions (2.4 branch, trunk) A Python source file containing: -- start snippet -- # -*- coding: mbcs -*- <1532 characters of code or comments> x = {} -- end snippet -- Will yield a SyntaxError when attempting to import the module. Running the module as a script does not provoke the error. To reproduce, there must be exactly 1532 characters where specified (see the attached file for a demo). Adding or removing even a single character will prevent the error. It is possible to replace characters with any others, including valid code, and still see the error - however, the number of characters must remain the same .cr/lf pairs can also be replaced with any other 2 characters. There are other "block sizes" that will provoke the error, but this is the only one I have nailed. Apart from the "block" of 1532 characters, the coding line and the blank line before the dict assignment also appear critical. Unlike the other characters in the block, this last cr/lf pair can not be replaced with comments. I can't provoke the error with other encodings (note there are no encoded characters in the sample - it is trivial). To reproduce, save the attached file on Windows and execute: > python -c "import foo2" Traceback (most recent call last): File "", line 1, in ? File "foo2.py", line 24 x = {} ^ SyntaxError: invalid syntax Note that Python 2.3 and earlier all work. Also note that "python foo2.py" also works. The code is clearly valid. Haven't tried to repro on Linux (mbcs isn't available there, and I can't get a test case that doesn't use it) Other pointers/notes: pywin32 bug 1085454 is related to long-lines, by all accounts that underlying error has been fixed - I can't verify this as pywin32 no longer generates insanely long lines. I can confirm Python bugs 1101726/1089395 still crashes Python 2.3+. I believe all (including this) are discrete bugs. [foo2.py is my attachment - ya gotta love sourceforge :)] ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-03-20 10:28 Message: Logged In: YES user_id=539787 Useful pointers: in Python-dev, this has been characterised as related to pywin32 bug 1085454. Also related to www.python.org/sf/1101726 and www.python.org/sf/1089395. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 From noreply at sourceforge.net Thu Aug 4 21:30:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Aug 2005 12:30:41 -0700 Subject: [ python-Bugs-1252149 ] IOError after normal write Message-ID: Bugs item #1252149, was opened at 2005-08-04 19:30 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=1252149&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Patrick Gerken (patrick_gerken) Assigned to: Nobody/Anonymous (nobody) Summary: IOError after normal write Initial Comment: After some Bughunting of Code with ConfigParser stuff which worked under Linux and didn't under Windows, it all boiled down to these three lines of codes: fp = open('bla','w+' fp.readline() fp.write('bla') Traceback (most recent call last): File "", line 1, in ? fp.write('bla') IOError: (0, 'Error') The same test under linux is a success. These teste have been run on the newest XP with python 2.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252149&group_id=5470 From noreply at sourceforge.net Thu Aug 4 21:51:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Aug 2005 12:51:09 -0700 Subject: [ python-Bugs-1252149 ] IOError after normal write Message-ID: Bugs item #1252149, was opened at 2005-08-04 15:30 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252149&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Patrick Gerken (patrick_gerken) Assigned to: Nobody/Anonymous (nobody) Summary: IOError after normal write Initial Comment: After some Bughunting of Code with ConfigParser stuff which worked under Linux and didn't under Windows, it all boiled down to these three lines of codes: fp = open('bla','w+' fp.readline() fp.write('bla') Traceback (most recent call last): File "", line 1, in ? fp.write('bla') IOError: (0, 'Error') The same test under linux is a success. These teste have been run on the newest XP with python 2.4.1. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-08-04 15:51 Message: Logged In: YES user_id=31435 Well, this is pilot error, inherited from the limitations of C I/O: the effect of mixing reads with writes on a file open for update is entirely undefined unless a file-positioning operation occurs between them (for example, a seek()). I can't guess what you expect to happen, but seems most likely that what you intend could be obtained reliably by inserting fp.seek(fp.tell()) between your readline() and your write(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252149&group_id=5470 From noreply at sourceforge.net Fri Aug 5 16:50:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 05 Aug 2005 07:50:34 -0700 Subject: [ python-Bugs-1251300 ] Decoding with unicode_internal segfaults on UCS-4 builds Message-ID: Bugs item #1251300, was opened at 2005-08-03 21:49 Message generated for change (Comment added) made by nhaldimann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&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: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nik Haldimann (nhaldimann) Assigned to: M.-A. Lemburg (lemburg) Summary: Decoding with unicode_internal segfaults on UCS-4 builds Initial Comment: On UCS-4 builds, decoding a byte string with the unicode_internal codec doesn't correctly work for code points from 0x80000000 upwards and even segfaults. I have observed the same behaviour on 2.5 from CVS and 2.4.0 on OS X/PowerPC as well as on 2.3.5 on Linux/x86. Here's an example: Python 2.5a0 (#1, Aug 3 2005, 21:34:05) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> "\x7f\xff\xff\xff".decode("unicode_internal") u'\U7fffffff' >>> "\x80\x00\x00\x00".decode("unicode_internal") u'\x00' >>> "\x80\x00\x00\x01".decode("unicode_internal") u'\x01' >>> "\x81\x00\x00\x00".decode("unicode_internal") Segmentation fault On little endian architectures the byte strings must be reversed for the same effect. I'm not sure if I understand what's going on, but I guess there are 2 solution strategies: 1. Make unicode_internal work for any code point up to 0xFFFFFFFF. 2. Make unicode_internal raise a UnicodeDecodeError for anything above 0x10FFFF (== sys.maxunicode for UCS-4 builds). It seems like there are no unicode code points above 0x10FFFF, so the latter solution feels more correct to me, even though it might break backwards compatibility a tiny bit. The unicodeescape codec already does a similar thing: >>> u"\U00110000" UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character ---------------------------------------------------------------------- >Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 16:50 Message: Logged In: YES user_id=1317086 OK, I put something together. Please review carefully as I'm not very familiar with the C API. I have tested this with the CVS HEAD on OS X and Linux. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:41 Message: Logged In: YES user_id=38388 I think solution 2 is the right approach, since UCS-4 only has 0x10FFFF possible code points. Could you provide a patch ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&group_id=5470 From noreply at sourceforge.net Fri Aug 5 18:03:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 05 Aug 2005 09:03:26 -0700 Subject: [ python-Bugs-1251300 ] Decoding with unicode_internal segfaults on UCS-4 builds Message-ID: Bugs item #1251300, was opened at 2005-08-03 21:49 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&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: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nik Haldimann (nhaldimann) Assigned to: M.-A. Lemburg (lemburg) Summary: Decoding with unicode_internal segfaults on UCS-4 builds Initial Comment: On UCS-4 builds, decoding a byte string with the unicode_internal codec doesn't correctly work for code points from 0x80000000 upwards and even segfaults. I have observed the same behaviour on 2.5 from CVS and 2.4.0 on OS X/PowerPC as well as on 2.3.5 on Linux/x86. Here's an example: Python 2.5a0 (#1, Aug 3 2005, 21:34:05) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> "\x7f\xff\xff\xff".decode("unicode_internal") u'\U7fffffff' >>> "\x80\x00\x00\x00".decode("unicode_internal") u'\x00' >>> "\x80\x00\x00\x01".decode("unicode_internal") u'\x01' >>> "\x81\x00\x00\x00".decode("unicode_internal") Segmentation fault On little endian architectures the byte strings must be reversed for the same effect. I'm not sure if I understand what's going on, but I guess there are 2 solution strategies: 1. Make unicode_internal work for any code point up to 0xFFFFFFFF. 2. Make unicode_internal raise a UnicodeDecodeError for anything above 0x10FFFF (== sys.maxunicode for UCS-4 builds). It seems like there are no unicode code points above 0x10FFFF, so the latter solution feels more correct to me, even though it might break backwards compatibility a tiny bit. The unicodeescape codec already does a similar thing: >>> u"\U00110000" UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-08-05 18:03 Message: Logged In: YES user_id=89016 Your patch doesn't support PEP 293 error handlers. Could you add support for that? ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 16:50 Message: Logged In: YES user_id=1317086 OK, I put something together. Please review carefully as I'm not very familiar with the C API. I have tested this with the CVS HEAD on OS X and Linux. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:41 Message: Logged In: YES user_id=38388 I think solution 2 is the right approach, since UCS-4 only has 0x10FFFF possible code points. Could you provide a patch ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&group_id=5470 From noreply at sourceforge.net Fri Aug 5 18:35:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 05 Aug 2005 09:35:52 -0700 Subject: [ python-Bugs-1251300 ] Decoding with unicode_internal segfaults on UCS-4 builds Message-ID: Bugs item #1251300, was opened at 2005-08-03 21:49 Message generated for change (Comment added) made by nhaldimann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&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: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nik Haldimann (nhaldimann) Assigned to: M.-A. Lemburg (lemburg) Summary: Decoding with unicode_internal segfaults on UCS-4 builds Initial Comment: On UCS-4 builds, decoding a byte string with the unicode_internal codec doesn't correctly work for code points from 0x80000000 upwards and even segfaults. I have observed the same behaviour on 2.5 from CVS and 2.4.0 on OS X/PowerPC as well as on 2.3.5 on Linux/x86. Here's an example: Python 2.5a0 (#1, Aug 3 2005, 21:34:05) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> "\x7f\xff\xff\xff".decode("unicode_internal") u'\U7fffffff' >>> "\x80\x00\x00\x00".decode("unicode_internal") u'\x00' >>> "\x80\x00\x00\x01".decode("unicode_internal") u'\x01' >>> "\x81\x00\x00\x00".decode("unicode_internal") Segmentation fault On little endian architectures the byte strings must be reversed for the same effect. I'm not sure if I understand what's going on, but I guess there are 2 solution strategies: 1. Make unicode_internal work for any code point up to 0xFFFFFFFF. 2. Make unicode_internal raise a UnicodeDecodeError for anything above 0x10FFFF (== sys.maxunicode for UCS-4 builds). It seems like there are no unicode code points above 0x10FFFF, so the latter solution feels more correct to me, even though it might break backwards compatibility a tiny bit. The unicodeescape codec already does a similar thing: >>> u"\U00110000" UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character ---------------------------------------------------------------------- >Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 18:35 Message: Logged In: YES user_id=1317086 Ah, that PEP clears some things up for me. I will look into it, but I hope you realize this requires tinkering with unicodeobject.c since the error handler code seems to live there. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-05 18:03 Message: Logged In: YES user_id=89016 Your patch doesn't support PEP 293 error handlers. Could you add support for that? ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 16:50 Message: Logged In: YES user_id=1317086 OK, I put something together. Please review carefully as I'm not very familiar with the C API. I have tested this with the CVS HEAD on OS X and Linux. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:41 Message: Logged In: YES user_id=38388 I think solution 2 is the right approach, since UCS-4 only has 0x10FFFF possible code points. Could you provide a patch ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&group_id=5470 From noreply at sourceforge.net Fri Aug 5 19:53:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 05 Aug 2005 10:53:44 -0700 Subject: [ python-Bugs-1249749 ] Encodings and aliases do not match runtime Message-ID: 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', 'iso_8859_7', 'iso_ir_126', 'elot_928', 'iso_8859_7_1987', 'csisolatingreek', 'greek'] iso8859_8 ['iso_8859_8_1988', 'iso_ir_138', 'iso_8859_8', 'csisolatinhebrew', 'hebrew'] iso8859_9 ['l5', 'iso_8859_9_1989', 'iso_8859_9', 'csisolatin5', 'latin5', 'iso_ir_148'] johab ['cp1361', 'ms1361'] koi8_r ['cskoi8r'] latin_1 ['iso8859', 'csisolatin1', 'latin', 'l1', 'iso_ir_100', 'ibm819', 'cp819', 'iso_8859_1', 'latin1', 'iso_8859_1_1987', '8859'] mac_cyrillic ['maccyrillic'] mac_greek ['macgreek'] mac_iceland ['maciceland'] mac_latin2 ['maccentraleurope', 'maclatin2'] mac_roman ['macroman'] mac_turkish ['macturkish'] mbcs ['dbcs'] ptcp154 ['cp154', 'cyrillic-asian', 'csptcp154', 'pt154'] quopri_codec ['quopri', 'quoted_printable', 'quotedprintable'] rot_13 ['rot13'] shift_jis ['s_jis', 'sjis', 'shiftjis', 'csshiftjis'] shift_jis_2004 ['shiftjis2004', 's_jis_2004', 'sjis_2004'] shift_jisx0213 ['shiftjisx0213', 'sjisx0213', 's_jisx0213'] tactis ['tis260'] tis_620 ['tis620', 'tis_620_2529_1', 'tis_620_2529_0', 'iso_ir_166', 'tis_620_0'] utf_16 ['utf16', 'u16'] utf_16_be ['utf_16be', 'unicodebigunmarked'] utf_16_le ['utf_16le', 'unicodelittleunmarked'] utf_7 ['u7', 'utf7'] utf_8 ['u8', 'utf', 'utf8_ucs4', 'utf8_ucs2', 'utf8'] uu_codec ['uu'] zlib_codec ['zlib', 'zip'] ---------------------------------------------------------------------- >Comment By: liturgist (liturgist) Date: 2005-08-05 12:53 Message: Logged In: YES user_id=197677 I would very much like to produce the doc table from code. However, I have a few questions. It seems that encodings.aliases.aliases is a list of all encodings and not necessarily those supported on all machines. Ie. mbcs on UNIX or embedded systems that might exclude some large character sets to save space. Is this correct? If so, will it remain that way? To find out if an encoding is supported on the current machine, the code should handle the exception generated when codecs.lookup() fails. Right? To generate the table, I need to produce the "Languages" field. This information does not seem to be available from the Python runtime. I would much rather see this information, including a localized version of the string, come from the Python runtime, rather than hardcode it into the script. Is that a possibility? Would it be a better approach? The non-language oriented encodings such as base_64 and rot_13 do not seem to have anything that distinguishes them from human languages. How can these be separated out without hardcoding? Likewise, the non-language encodings have an "Operand type" field which would need to be generated. My feeling is, again, that this should come from the Python runtime and not be hardcoded into the doc generation script. Any suggestions? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 09:47 Message: Logged In: YES user_id=38388 Doc patches are welcome - perhaps you could enhance your script to have the doc table generated from the available codecs and aliases ?! Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249749&group_id=5470 From noreply at sourceforge.net Fri Aug 5 19:55:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 05 Aug 2005 10:55:20 -0700 Subject: [ python-Bugs-1252733 ] os.system on win32 can't handle pathnames with spaces Message-ID: Bugs item #1252733, was opened at 2005-08-05 20:55 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=1252733&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: Ori Avtalion (salty-horse) Assigned to: Nobody/Anonymous (nobody) Summary: os.system on win32 can't handle pathnames with spaces Initial Comment: when calling os.system("file with spaces.exe"), Windows outputs the following: 'file' is not recognized as an internal or external command, operable program or batch file. I tried quoting the filename. Still got the same error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252733&group_id=5470 From noreply at sourceforge.net Fri Aug 5 20:41:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 05 Aug 2005 11:41:35 -0700 Subject: [ python-Bugs-1252733 ] os.system on win32 can't handle pathnames with spaces Message-ID: Bugs item #1252733, was opened at 2005-08-05 19:55 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252733&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: Ori Avtalion (salty-horse) Assigned to: Nobody/Anonymous (nobody) Summary: os.system on win32 can't handle pathnames with spaces Initial Comment: when calling os.system("file with spaces.exe"), Windows outputs the following: 'file' is not recognized as an internal or external command, operable program or batch file. I tried quoting the filename. Still got the same error. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-05 20:41 Message: Logged In: YES user_id=1188172 Can you escape the spaces with backslashes? Or with circumflexes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252733&group_id=5470 From noreply at sourceforge.net Fri Aug 5 23:08:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 05 Aug 2005 14:08:23 -0700 Subject: [ python-Bugs-1251300 ] Decoding with unicode_internal segfaults on UCS-4 builds Message-ID: Bugs item #1251300, was opened at 2005-08-03 21:49 Message generated for change (Comment added) made by nhaldimann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&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: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nik Haldimann (nhaldimann) Assigned to: M.-A. Lemburg (lemburg) Summary: Decoding with unicode_internal segfaults on UCS-4 builds Initial Comment: On UCS-4 builds, decoding a byte string with the unicode_internal codec doesn't correctly work for code points from 0x80000000 upwards and even segfaults. I have observed the same behaviour on 2.5 from CVS and 2.4.0 on OS X/PowerPC as well as on 2.3.5 on Linux/x86. Here's an example: Python 2.5a0 (#1, Aug 3 2005, 21:34:05) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> "\x7f\xff\xff\xff".decode("unicode_internal") u'\U7fffffff' >>> "\x80\x00\x00\x00".decode("unicode_internal") u'\x00' >>> "\x80\x00\x00\x01".decode("unicode_internal") u'\x01' >>> "\x81\x00\x00\x00".decode("unicode_internal") Segmentation fault On little endian architectures the byte strings must be reversed for the same effect. I'm not sure if I understand what's going on, but I guess there are 2 solution strategies: 1. Make unicode_internal work for any code point up to 0xFFFFFFFF. 2. Make unicode_internal raise a UnicodeDecodeError for anything above 0x10FFFF (== sys.maxunicode for UCS-4 builds). It seems like there are no unicode code points above 0x10FFFF, so the latter solution feels more correct to me, even though it might break backwards compatibility a tiny bit. The unicodeescape codec already does a similar thing: >>> u"\U00110000" UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character ---------------------------------------------------------------------- >Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 23:08 Message: Logged In: YES user_id=1317086 Here's the patch with error handler support + test. Again: Please review carefully. ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 18:35 Message: Logged In: YES user_id=1317086 Ah, that PEP clears some things up for me. I will look into it, but I hope you realize this requires tinkering with unicodeobject.c since the error handler code seems to live there. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-05 18:03 Message: Logged In: YES user_id=89016 Your patch doesn't support PEP 293 error handlers. Could you add support for that? ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 16:50 Message: Logged In: YES user_id=1317086 OK, I put something together. Please review carefully as I'm not very familiar with the C API. I have tested this with the CVS HEAD on OS X and Linux. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:41 Message: Logged In: YES user_id=38388 I think solution 2 is the right approach, since UCS-4 only has 0x10FFFF possible code points. Could you provide a patch ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&group_id=5470 From noreply at sourceforge.net Sat Aug 6 12:13:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Aug 2005 03:13:24 -0700 Subject: [ python-Bugs-1252733 ] os.system on win32 can't handle pathnames with spaces Message-ID: Bugs item #1252733, was opened at 2005-08-05 20:55 Message generated for change (Comment added) made by salty-horse You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252733&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: Closed >Resolution: Invalid Priority: 5 Submitted By: Ori Avtalion (salty-horse) Assigned to: Nobody/Anonymous (nobody) Summary: os.system on win32 can't handle pathnames with spaces Initial Comment: when calling os.system("file with spaces.exe"), Windows outputs the following: 'file' is not recognized as an internal or external command, operable program or batch file. I tried quoting the filename. Still got the same error. ---------------------------------------------------------------------- >Comment By: Ori Avtalion (salty-horse) Date: 2005-08-06 13:13 Message: Logged In: YES user_id=854801 os.execute("\file with spaces\") seems to solve the problem. Documentation here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp Turns out this is NOT a bug. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-05 21:41 Message: Logged In: YES user_id=1188172 Can you escape the spaces with backslashes? Or with circumflexes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252733&group_id=5470 From noreply at sourceforge.net Sat Aug 6 13:56:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Aug 2005 04:56:10 -0700 Subject: [ python-Bugs-1251921 ] Fail codecs.lookup() on 'mbcs' and 'tactis' Message-ID: Bugs item #1251921, was opened at 2005-08-04 16:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&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: Unicode Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Fail codecs.lookup() on 'mbcs' and 'tactis' Initial Comment: $ python Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import codecs >>> codecs.lookup('ascii') (, , , ) >>> codecs.lookup('mbcs') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/encodings/__init__.py", line 96, in search_function globals(), locals(), _import_tail) File "/usr/lib/python2.4/encodings/mbcs.py", line 14, in ? class Codec(codecs.Codec): File "/usr/lib/python2.4/encodings/mbcs.py", line 18, in Codec encode = codecs.mbcs_encode AttributeError: 'module' object has no attribute 'mbcs_encode' >>> codecs.lookup('tactis') Traceback (most recent call last): File "", line 1, in ? LookupError: unknown encoding: tactis ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 13:56 Message: Logged In: YES user_id=21627 Yes, UTF-8 is a multi-byte character set, but no, UTF-8 and mbcs are not synonyms. See http://docs.python.org/lib/standard-encodings.html for the documentation. encodings.aliases.aliases is no registration - it is an alias databse. So if somebody refers to "dbcs", this will be aliased to "mbcs". That does not mean "mbcs" needs to be supported - it only means "dbcs" is not supported on Linux, either. tactis was never part of a Python release, so its lack is not a bug. Closing this report as invalid. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-04 17:00 Message: Logged In: YES user_id=197677 If 'mbcs' is Windows-only, then why does it appear in the list of registered codecs in encodings.aliases.aliases on the Linux platform? Shouldn't it not be registered on other platforms? ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-04 16:55 Message: Logged In: YES user_id=197677 UTF-8 is an MBCS encoding in that is is a "multiple byte character set", right? :-) UTF-16 is an MSCS; multiple short character set. There appears to have been some discussion on 'tactis' and 'tactis260' earlier in bug 854511. http://mail.python.org/pipermail/python-bugs-list/2003-December/021394.html ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:38 Message: Logged In: YES user_id=38388 mbcs is only available on Windows. I'm not sure what happened to the tactis codec - it's possible that it never got checked in. Do you have a reference for the tactis encoding ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&group_id=5470 From noreply at sourceforge.net Sat Aug 6 14:41:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Aug 2005 05:41:24 -0700 Subject: [ python-Bugs-1249749 ] Encodings and aliases do not match runtime Message-ID: 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', 'iso_8859_7', 'iso_ir_126', 'elot_928', 'iso_8859_7_1987', 'csisolatingreek', 'greek'] iso8859_8 ['iso_8859_8_1988', 'iso_ir_138', 'iso_8859_8', 'csisolatinhebrew', 'hebrew'] iso8859_9 ['l5', 'iso_8859_9_1989', 'iso_8859_9', 'csisolatin5', 'latin5', 'iso_ir_148'] johab ['cp1361', 'ms1361'] koi8_r ['cskoi8r'] latin_1 ['iso8859', 'csisolatin1', 'latin', 'l1', 'iso_ir_100', 'ibm819', 'cp819', 'iso_8859_1', 'latin1', 'iso_8859_1_1987', '8859'] mac_cyrillic ['maccyrillic'] mac_greek ['macgreek'] mac_iceland ['maciceland'] mac_latin2 ['maccentraleurope', 'maclatin2'] mac_roman ['macroman'] mac_turkish ['macturkish'] mbcs ['dbcs'] ptcp154 ['cp154', 'cyrillic-asian', 'csptcp154', 'pt154'] quopri_codec ['quopri', 'quoted_printable', 'quotedprintable'] rot_13 ['rot13'] shift_jis ['s_jis', 'sjis', 'shiftjis', 'csshiftjis'] shift_jis_2004 ['shiftjis2004', 's_jis_2004', 'sjis_2004'] shift_jisx0213 ['shiftjisx0213', 'sjisx0213', 's_jisx0213'] tactis ['tis260'] tis_620 ['tis620', 'tis_620_2529_1', 'tis_620_2529_0', 'iso_ir_166', 'tis_620_0'] utf_16 ['utf16', 'u16'] utf_16_be ['utf_16be', 'unicodebigunmarked'] utf_16_le ['utf_16le', 'unicodelittleunmarked'] utf_7 ['u7', 'utf7'] utf_8 ['u8', 'utf', 'utf8_ucs4', 'utf8_ucs2', 'utf8'] uu_codec ['uu'] zlib_codec ['zlib', 'zip'] ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 14:41 Message: Logged In: YES user_id=21627 I would not like to see the documentation contain a complete list of all aliases. The documentation points out that this are "a few common aliases", ie. I selected aliases that people are likely to encounter, and are encouraged to use. I don't think it is useful to produce the table from the code. If you want to know everything in aliases, just look at aliases directly. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-05 19:53 Message: Logged In: YES user_id=197677 I would very much like to produce the doc table from code. However, I have a few questions. It seems that encodings.aliases.aliases is a list of all encodings and not necessarily those supported on all machines. Ie. mbcs on UNIX or embedded systems that might exclude some large character sets to save space. Is this correct? If so, will it remain that way? To find out if an encoding is supported on the current machine, the code should handle the exception generated when codecs.lookup() fails. Right? To generate the table, I need to produce the "Languages" field. This information does not seem to be available from the Python runtime. I would much rather see this information, including a localized version of the string, come from the Python runtime, rather than hardcode it into the script. Is that a possibility? Would it be a better approach? The non-language oriented encodings such as base_64 and rot_13 do not seem to have anything that distinguishes them from human languages. How can these be separated out without hardcoding? Likewise, the non-language encodings have an "Operand type" field which would need to be generated. My feeling is, again, that this should come from the Python runtime and not be hardcoded into the doc generation script. Any suggestions? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:47 Message: Logged In: YES user_id=38388 Doc patches are welcome - perhaps you could enhance your script to have the doc table generated from the available codecs and aliases ?! Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249749&group_id=5470 From noreply at sourceforge.net Sat Aug 6 14:43:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Aug 2005 05:43:38 -0700 Subject: [ python-Bugs-1244610 ] 2.4.1 build fails on OpenBSD 3.7 Message-ID: Bugs item #1244610, was opened at 2005-07-25 18:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&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: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 build fails on OpenBSD 3.7 Initial Comment: Python 2.4.1, OpenBSD 3.7, gcc (GCC) 3.3.5 (propolice). I'm including the logs here because they are short. "./configure" printed the following: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------------ ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ------------------------------------------------ ## checking for curses.h... yes This warning was printed for curses.h, ncurses.h, sys/audioio.h, and sys/lock.h. (The reference to "Autoconf documentation" is useless, because autoconf is not used during the configure process, and is not even installed on the system where I was doing the build.) Then: % make gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c In file included from /usr/include/sys/select.h:38, from Include/pyport.h:116, from Include/Python.h:55, from Modules/python.c:3: /usr/include/sys/event.h:53: error: syntax error before "u_int" /usr/include/sys/event.h:55: error: syntax error before "u_short" *** Error code 1 Stop in /usr/src/Python-2.4.1. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 14:43 Message: Logged In: YES user_id=21627 So can you tell us whether there are missing prerequisite headers? One would need to have access to your operating system to resolve this issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 From noreply at sourceforge.net Sat Aug 6 14:45:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Aug 2005 05:45:30 -0700 Subject: [ python-Bugs-1241006 ] Distutils does not use logging Message-ID: Bugs item #1241006, was opened at 2005-07-19 19:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&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: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Giles Antonio Radford (mewf) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils does not use logging Initial Comment: distutils.log creates its own PEP 282-like logger class, which is fine from the distutils point of view, but not exactly brilliant if you want to intercept the calls using the logging facilities that have been in python since 2.3. Recommended fix: If, in fact, distutils.log has to be kept compatible with 2.1 as is claimed in the source file then something along the lines of: try: import logging _global_log = logging.getLogger('distutils') except ImportError: #insert current Log class definition here _global_log = Log() Also, changing the values for DEBUG, INFO, WARN, ERROR and FATAL to be the same as the ones in logging.py is probably a good idea. The distutils logger should have its own formatter that prints out lines as the thing currently does, but this formatter should be set within the code for setup() rather than in the log module. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 14:45 Message: Logged In: YES user_id=21627 Can you provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&group_id=5470 From noreply at sourceforge.net Sat Aug 6 14:46:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Aug 2005 05:46:29 -0700 Subject: [ python-Bugs-1239948 ] distutils: MetroWerks support can go Message-ID: Bugs item #1239948, was opened at 2005-07-17 23:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239948&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: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Anthony Baxter (anthonybaxter) Summary: distutils: MetroWerks support can go Initial Comment: I'm not sure how far back the current distutils (i.e. the one from the CVS trunk) is supposed to be backward compatible, but from 2.4 onwards Python does not support Mac OS 9 anymore, and therefore support for the MetroWerks C compiler can be ripped out. Theoretically there's an MW compiler on windows too, but nobody uses it and the mwerkscompiler object in distutils currently only support the Mac compiler. And actually only that in the exact way that MacPython used it. I'm basically asking for an opinion here: is it a good idea to rip mwerkscompiler out. Feel free to assign back to me to do the work. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 14:46 Message: Logged In: YES user_id=21627 distutils is meant to be compatible with Python 2.1. Don't know whether this means it still needs to support Metrowerks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239948&group_id=5470 From noreply at sourceforge.net Sat Aug 6 14:47:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Aug 2005 05:47:38 -0700 Subject: [ python-Bugs-1232947 ] non-admin install may fail (win xp pro) Message-ID: Bugs item #1232947, was opened at 2005-07-05 20:31 Message generated for change (Comment added) made by loewis 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: Closed >Resolution: Works For Me Priority: 5 Submitted By: Patrick Vrijlandt (pvrijlandt) Assigned to: Nobody/Anonymous (nobody) 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: 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 From noreply at sourceforge.net Sat Aug 6 14:48:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Aug 2005 05:48:29 -0700 Subject: [ python-Bugs-1232947 ] non-admin install may fail (win xp pro) Message-ID: Bugs item #1232947, was opened at 2005-07-05 20:31 Message generated for change (Comment added) made by loewis 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: Nobody/Anonymous (nobody) 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: 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 From noreply at sourceforge.net Sat Aug 6 14:49:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Aug 2005 05:49:05 -0700 Subject: [ python-Bugs-1249749 ] Encodings and aliases do not match runtime Message-ID: Bugs item #1249749, was opened at 2005-08-01 20:23 Message generated for change (Comment added) made by lemburg 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', 'iso_8859_7', 'iso_ir_126', 'elot_928', 'iso_8859_7_1987', 'csisolatingreek', 'greek'] iso8859_8 ['iso_8859_8_1988', 'iso_ir_138', 'iso_8859_8', 'csisolatinhebrew', 'hebrew'] iso8859_9 ['l5', 'iso_8859_9_1989', 'iso_8859_9', 'csisolatin5', 'latin5', 'iso_ir_148'] johab ['cp1361', 'ms1361'] koi8_r ['cskoi8r'] latin_1 ['iso8859', 'csisolatin1', 'latin', 'l1', 'iso_ir_100', 'ibm819', 'cp819', 'iso_8859_1', 'latin1', 'iso_8859_1_1987', '8859'] mac_cyrillic ['maccyrillic'] mac_greek ['macgreek'] mac_iceland ['maciceland'] mac_latin2 ['maccentraleurope', 'maclatin2'] mac_roman ['macroman'] mac_turkish ['macturkish'] mbcs ['dbcs'] ptcp154 ['cp154', 'cyrillic-asian', 'csptcp154', 'pt154'] quopri_codec ['quopri', 'quoted_printable', 'quotedprintable'] rot_13 ['rot13'] shift_jis ['s_jis', 'sjis', 'shiftjis', 'csshiftjis'] shift_jis_2004 ['shiftjis2004', 's_jis_2004', 'sjis_2004'] shift_jisx0213 ['shiftjisx0213', 'sjisx0213', 's_jisx0213'] tactis ['tis260'] tis_620 ['tis620', 'tis_620_2529_1', 'tis_620_2529_0', 'iso_ir_166', 'tis_620_0'] utf_16 ['utf16', 'u16'] utf_16_be ['utf_16be', 'unicodebigunmarked'] utf_16_le ['utf_16le', 'unicodelittleunmarked'] utf_7 ['u7', 'utf7'] utf_8 ['u8', 'utf', 'utf8_ucs4', 'utf8_ucs2', 'utf8'] uu_codec ['uu'] zlib_codec ['zlib', 'zip'] ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-06 14:49 Message: Logged In: YES user_id=38388 Martin, I don't see any problem with putting the complete list of aliases into the documentation. liturgist, don't worry about hard-coding things into the script. The extra information Martin gave in the table is not likely going to become part of the standard lib, because there's no a lot you can do with it programmatically. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 14:41 Message: Logged In: YES user_id=21627 I would not like to see the documentation contain a complete list of all aliases. The documentation points out that this are "a few common aliases", ie. I selected aliases that people are likely to encounter, and are encouraged to use. I don't think it is useful to produce the table from the code. If you want to know everything in aliases, just look at aliases directly. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-05 19:53 Message: Logged In: YES user_id=197677 I would very much like to produce the doc table from code. However, I have a few questions. It seems that encodings.aliases.aliases is a list of all encodings and not necessarily those supported on all machines. Ie. mbcs on UNIX or embedded systems that might exclude some large character sets to save space. Is this correct? If so, will it remain that way? To find out if an encoding is supported on the current machine, the code should handle the exception generated when codecs.lookup() fails. Right? To generate the table, I need to produce the "Languages" field. This information does not seem to be available from the Python runtime. I would much rather see this information, including a localized version of the string, come from the Python runtime, rather than hardcode it into the script. Is that a possibility? Would it be a better approach? The non-language oriented encodings such as base_64 and rot_13 do not seem to have anything that distinguishes them from human languages. How can these be separated out without hardcoding? Likewise, the non-language encodings have an "Operand type" field which would need to be generated. My feeling is, again, that this should come from the Python runtime and not be hardcoded into the doc generation script. Any suggestions? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:47 Message: Logged In: YES user_id=38388 Doc patches are welcome - perhaps you could enhance your script to have the doc table generated from the available codecs and aliases ?! Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249749&group_id=5470 From noreply at sourceforge.net Sat Aug 6 14:51:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Aug 2005 05:51:33 -0700 Subject: [ python-Bugs-1251921 ] Fail codecs.lookup() on 'mbcs' and 'tactis' Message-ID: Bugs item #1251921, was opened at 2005-08-04 16:11 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&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: Unicode Group: Python 2.4 >Status: Open >Resolution: Remind Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Fail codecs.lookup() on 'mbcs' and 'tactis' Initial Comment: $ python Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import codecs >>> codecs.lookup('ascii') (, , , ) >>> codecs.lookup('mbcs') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/encodings/__init__.py", line 96, in search_function globals(), locals(), _import_tail) File "/usr/lib/python2.4/encodings/mbcs.py", line 14, in ? class Codec(codecs.Codec): File "/usr/lib/python2.4/encodings/mbcs.py", line 18, in Codec encode = codecs.mbcs_encode AttributeError: 'module' object has no attribute 'mbcs_encode' >>> codecs.lookup('tactis') Traceback (most recent call last): File "", line 1, in ? LookupError: unknown encoding: tactis ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-06 14:51 Message: Logged In: YES user_id=38388 Reopened: this is indeed a bug - the tactis codec is referenced in the aliases table but was never added to the encodings package. Either the codec will have to be added, or the alias entry removed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 13:56 Message: Logged In: YES user_id=21627 Yes, UTF-8 is a multi-byte character set, but no, UTF-8 and mbcs are not synonyms. See http://docs.python.org/lib/standard-encodings.html for the documentation. encodings.aliases.aliases is no registration - it is an alias databse. So if somebody refers to "dbcs", this will be aliased to "mbcs". That does not mean "mbcs" needs to be supported - it only means "dbcs" is not supported on Linux, either. tactis was never part of a Python release, so its lack is not a bug. Closing this report as invalid. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-04 17:00 Message: Logged In: YES user_id=197677 If 'mbcs' is Windows-only, then why does it appear in the list of registered codecs in encodings.aliases.aliases on the Linux platform? Shouldn't it not be registered on other platforms? ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-04 16:55 Message: Logged In: YES user_id=197677 UTF-8 is an MBCS encoding in that is is a "multiple byte character set", right? :-) UTF-16 is an MSCS; multiple short character set. There appears to have been some discussion on 'tactis' and 'tactis260' earlier in bug 854511. http://mail.python.org/pipermail/python-bugs-list/2003-December/021394.html ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:38 Message: Logged In: YES user_id=38388 mbcs is only available on Windows. I'm not sure what happened to the tactis codec - it's possible that it never got checked in. Do you have a reference for the tactis encoding ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&group_id=5470 From noreply at sourceforge.net Sat Aug 6 14:58:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Aug 2005 05:58:06 -0700 Subject: [ python-Bugs-1232947 ] non-admin install may fail (win xp pro) Message-ID: Bugs item #1232947, was opened at 2005-07-05 20:31 Message generated for change (Comment added) made by loewis 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: 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 From noreply at sourceforge.net Sat Aug 6 15:19:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Aug 2005 06:19:08 -0700 Subject: [ python-Bugs-1226969 ] segfault in os module Message-ID: Bugs item #1226969, was opened at 2005-06-24 15:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226969&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: jacobo_es (jacobo_es) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in os module Initial Comment: python crashes when a bad parameters are passed to execl function of the os module: >>> import os >>> os.execl("/bin/bash") Segmentation Fault (core dumped) No matter the platform (on ppc raises a bus error) and the version of C compiler, always crashes, python versions used are 2.4.1 and 2.4c1. Proved on MacOSX (ppc), and Knoppix, Red Hat Enterprise and debian woody 3.0 (x86). However, on 2.2.3 version not crashes. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 15:19 Message: Logged In: YES user_id=21627 There is nothing wrong with Python here. It is not Python that crashes, but /bin/bash. Just try a different binary (/usr/bin/id worked for me); use strace to see that it is indeed the new process that crashes. Closing as invalid. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 08:19 Message: Logged In: YES user_id=1188172 First, Python does not call the C execl functions, but translates them to execv calls. For execv called like Python does: ~/tmp> ./execv zsh: 15395 segmentation fault ./execv ~/tmp> cat execv.c #include #include int main() { const char* args[1]; args[0] = NULL; execv("/bin/bash", args); return errno; } For execl on the C layer, my Linux doesn't want that: ~/tmp> gcc -o execl execl.c execl.c: In function `main': execl.c:4: error: too few arguments to function 'execl' ~/tmp> cat execv.c #include int main() { execl("/bin/bash"); return 0; } ---------------------------------------------------------------------- Comment By: jacobo_es (jacobo_es) Date: 2005-06-26 01:15 Message: Logged In: YES user_id=1302185 I tried this directly on the C layer, too, and not raises a signal 11, segmentation fault, just the function execl() isn't executed and the program flow goes, not raises a sigsegv, and that's not happen in the same way in python, that abort the python interpreter and dump a core file. -( tmp )- ./p execl not executed. -( tmp )- cat p.c #include int main() { execl("/bin/bash"); fprintf(stderr, "execl not executed.\n"); exit(-1); } ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-24 16:53 Message: Logged In: YES user_id=1188172 This behaviour was introduced with the fixing of bug #952953, where someone complained that he couldn't call execl with only one argument. I tried this directly on the C layer on Linux, and it segfaults too. Are there OSes where this is legal? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226969&group_id=5470 From noreply at sourceforge.net Sat Aug 6 18:46:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Aug 2005 09:46:45 -0700 Subject: [ python-Bugs-1241006 ] Distutils does not use logging Message-ID: Bugs item #1241006, was opened at 2005-07-19 17:21 Message generated for change (Comment added) made by mewf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&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: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Giles Antonio Radford (mewf) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils does not use logging Initial Comment: distutils.log creates its own PEP 282-like logger class, which is fine from the distutils point of view, but not exactly brilliant if you want to intercept the calls using the logging facilities that have been in python since 2.3. Recommended fix: If, in fact, distutils.log has to be kept compatible with 2.1 as is claimed in the source file then something along the lines of: try: import logging _global_log = logging.getLogger('distutils') except ImportError: #insert current Log class definition here _global_log = Log() Also, changing the values for DEBUG, INFO, WARN, ERROR and FATAL to be the same as the ones in logging.py is probably a good idea. The distutils logger should have its own formatter that prints out lines as the thing currently does, but this formatter should be set within the code for setup() rather than in the log module. ---------------------------------------------------------------------- >Comment By: Giles Antonio Radford (mewf) Date: 2005-08-06 16:46 Message: Logged In: YES user_id=859703 Yes, though I'm offline for most of this week, I'll try and give it a go for next weekend. Does it need to be kept compatible with python 2.1? Or is 2.3 and above OK? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 12:45 Message: Logged In: YES user_id=21627 Can you provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&group_id=5470 From noreply at sourceforge.net Sat Aug 6 20:00:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Aug 2005 11:00:40 -0700 Subject: [ python-Bugs-1241006 ] Distutils does not use logging Message-ID: Bugs item #1241006, was opened at 2005-07-19 19:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&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: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Giles Antonio Radford (mewf) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils does not use logging Initial Comment: distutils.log creates its own PEP 282-like logger class, which is fine from the distutils point of view, but not exactly brilliant if you want to intercept the calls using the logging facilities that have been in python since 2.3. Recommended fix: If, in fact, distutils.log has to be kept compatible with 2.1 as is claimed in the source file then something along the lines of: try: import logging _global_log = logging.getLogger('distutils') except ImportError: #insert current Log class definition here _global_log = Log() Also, changing the values for DEBUG, INFO, WARN, ERROR and FATAL to be the same as the ones in logging.py is probably a good idea. The distutils logger should have its own formatter that prints out lines as the thing currently does, but this formatter should be set within the code for setup() rather than in the log module. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 20:00 Message: Logged In: YES user_id=21627 It needs to stay backwards-compatible with 2.1, so you need to fallback if logging is not available. No need to hurry, though. ---------------------------------------------------------------------- Comment By: Giles Antonio Radford (mewf) Date: 2005-08-06 18:46 Message: Logged In: YES user_id=859703 Yes, though I'm offline for most of this week, I'll try and give it a go for next weekend. Does it need to be kept compatible with python 2.1? Or is 2.3 and above OK? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 14:45 Message: Logged In: YES user_id=21627 Can you provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&group_id=5470 From noreply at sourceforge.net Sat Aug 6 21:04:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Aug 2005 12:04:22 -0700 Subject: [ python-Bugs-1251921 ] Fail codecs.lookup() on 'mbcs' and 'tactis' Message-ID: Bugs item #1251921, was opened at 2005-08-04 09:11 Message generated for change (Comment added) made by liturgist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&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: Unicode Group: Python 2.4 Status: Open Resolution: Remind Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Fail codecs.lookup() on 'mbcs' and 'tactis' Initial Comment: $ python Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import codecs >>> codecs.lookup('ascii') (, , , ) >>> codecs.lookup('mbcs') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/encodings/__init__.py", line 96, in search_function globals(), locals(), _import_tail) File "/usr/lib/python2.4/encodings/mbcs.py", line 14, in ? class Codec(codecs.Codec): File "/usr/lib/python2.4/encodings/mbcs.py", line 18, in Codec encode = codecs.mbcs_encode AttributeError: 'module' object has no attribute 'mbcs_encode' >>> codecs.lookup('tactis') Traceback (most recent call last): File "", line 1, in ? LookupError: unknown encoding: tactis ---------------------------------------------------------------------- >Comment By: liturgist (liturgist) Date: 2005-08-06 14:04 Message: Logged In: YES user_id=197677 Where is bug 854511 regarding Thai encodings? The URL has some discussion of this bug on TISI and ISO encodings. http://mail.python.org/pipermail/python-bugs-list/2003-December/021394.html ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-06 07:51 Message: Logged In: YES user_id=38388 Reopened: this is indeed a bug - the tactis codec is referenced in the aliases table but was never added to the encodings package. Either the codec will have to be added, or the alias entry removed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 06:56 Message: Logged In: YES user_id=21627 Yes, UTF-8 is a multi-byte character set, but no, UTF-8 and mbcs are not synonyms. See http://docs.python.org/lib/standard-encodings.html for the documentation. encodings.aliases.aliases is no registration - it is an alias databse. So if somebody refers to "dbcs", this will be aliased to "mbcs". That does not mean "mbcs" needs to be supported - it only means "dbcs" is not supported on Linux, either. tactis was never part of a Python release, so its lack is not a bug. Closing this report as invalid. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-04 10:00 Message: Logged In: YES user_id=197677 If 'mbcs' is Windows-only, then why does it appear in the list of registered codecs in encodings.aliases.aliases on the Linux platform? Shouldn't it not be registered on other platforms? ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-04 09:55 Message: Logged In: YES user_id=197677 UTF-8 is an MBCS encoding in that is is a "multiple byte character set", right? :-) UTF-16 is an MSCS; multiple short character set. There appears to have been some discussion on 'tactis' and 'tactis260' earlier in bug 854511. http://mail.python.org/pipermail/python-bugs-list/2003-December/021394.html ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 09:38 Message: Logged In: YES user_id=38388 mbcs is only available on Windows. I'm not sure what happened to the tactis codec - it's possible that it never got checked in. Do you have a reference for the tactis encoding ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&group_id=5470 From noreply at sourceforge.net Sat Aug 6 21:09:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Aug 2005 12:09:17 -0700 Subject: [ python-Bugs-1251921 ] Fail codecs.lookup() on 'mbcs' and 'tactis' Message-ID: Bugs item #1251921, was opened at 2005-08-04 16:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&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: Unicode Group: Python 2.4 Status: Open Resolution: Remind Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Fail codecs.lookup() on 'mbcs' and 'tactis' Initial Comment: $ python Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import codecs >>> codecs.lookup('ascii') (, , , ) >>> codecs.lookup('mbcs') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/encodings/__init__.py", line 96, in search_function globals(), locals(), _import_tail) File "/usr/lib/python2.4/encodings/mbcs.py", line 14, in ? class Codec(codecs.Codec): File "/usr/lib/python2.4/encodings/mbcs.py", line 18, in Codec encode = codecs.mbcs_encode AttributeError: 'module' object has no attribute 'mbcs_encode' >>> codecs.lookup('tactis') Traceback (most recent call last): File "", line 1, in ? LookupError: unknown encoding: tactis ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 21:09 Message: Logged In: YES user_id=21627 It's not a bug, it's a feature request, and it's at http://python.org/sf/854511 I have rejected the request. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-06 21:04 Message: Logged In: YES user_id=197677 Where is bug 854511 regarding Thai encodings? The URL has some discussion of this bug on TISI and ISO encodings. http://mail.python.org/pipermail/python-bugs-list/2003-December/021394.html ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-06 14:51 Message: Logged In: YES user_id=38388 Reopened: this is indeed a bug - the tactis codec is referenced in the aliases table but was never added to the encodings package. Either the codec will have to be added, or the alias entry removed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 13:56 Message: Logged In: YES user_id=21627 Yes, UTF-8 is a multi-byte character set, but no, UTF-8 and mbcs are not synonyms. See http://docs.python.org/lib/standard-encodings.html for the documentation. encodings.aliases.aliases is no registration - it is an alias databse. So if somebody refers to "dbcs", this will be aliased to "mbcs". That does not mean "mbcs" needs to be supported - it only means "dbcs" is not supported on Linux, either. tactis was never part of a Python release, so its lack is not a bug. Closing this report as invalid. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-04 17:00 Message: Logged In: YES user_id=197677 If 'mbcs' is Windows-only, then why does it appear in the list of registered codecs in encodings.aliases.aliases on the Linux platform? Shouldn't it not be registered on other platforms? ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-04 16:55 Message: Logged In: YES user_id=197677 UTF-8 is an MBCS encoding in that is is a "multiple byte character set", right? :-) UTF-16 is an MSCS; multiple short character set. There appears to have been some discussion on 'tactis' and 'tactis260' earlier in bug 854511. http://mail.python.org/pipermail/python-bugs-list/2003-December/021394.html ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:38 Message: Logged In: YES user_id=38388 mbcs is only available on Windows. I'm not sure what happened to the tactis codec - it's possible that it never got checked in. Do you have a reference for the tactis encoding ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251921&group_id=5470 From noreply at sourceforge.net Sat Aug 6 23:22:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Aug 2005 14:22:39 -0700 Subject: [ python-Bugs-1239948 ] distutils: MetroWerks support can go Message-ID: Bugs item #1239948, was opened at 2005-07-17 23:44 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239948&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: Distutils Group: None >Status: Closed >Resolution: Later Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Anthony Baxter (anthonybaxter) Summary: distutils: MetroWerks support can go Initial Comment: I'm not sure how far back the current distutils (i.e. the one from the CVS trunk) is supposed to be backward compatible, but from 2.4 onwards Python does not support Mac OS 9 anymore, and therefore support for the MetroWerks C compiler can be ripped out. Theoretically there's an MW compiler on windows too, but nobody uses it and the mwerkscompiler object in distutils currently only support the Mac compiler. And actually only that in the exact way that MacPython used it. I'm basically asking for an opinion here: is it a good idea to rip mwerkscompiler out. Feel free to assign back to me to do the work. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-08-06 23:22 Message: Logged In: YES user_id=45365 MacOS9 support is there up to 2.3. So then we should leave MertoWerks support in. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 14:46 Message: Logged In: YES user_id=21627 distutils is meant to be compatible with Python 2.1. Don't know whether this means it still needs to support Metrowerks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239948&group_id=5470 From noreply at sourceforge.net Sun Aug 7 19:40:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 07 Aug 2005 10:40:53 -0700 Subject: [ python-Bugs-1251631 ] Python 2.4.1 crashes when importing the attached script Message-ID: Bugs item #1251631, was opened at 2005-08-04 03:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251631&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: None Priority: 5 Submitted By: Viktor Ferenczi (complex) >Assigned to: Martin v. L?wis (loewis) Summary: Python 2.4.1 crashes when importing the attached script Initial Comment: OS: WinXP Prog. ENG SP1 Python: 2.4.1 MSI installer downloaded from python.org Python crashes or rarely raises MemoryError or SyntaxError when trying to import/execute the script attached. The behaviour changes when some lines are modified, but mostly crashes the python process with a memory access violation. The python process used 4.2Mbytes of system memory when crashed. There were more than 500Mbytes free. Register dump: EAX = 00A8CC61 EBX = 0000000A ECX = 00000000 EDX = 00000000 ESI = 00A10DA0 EDI = 00000022 EIP = 1E0A7F10 ESP = 0021FD98 EBP = 00000222 EFlags = 00000293 Other registers are irrelevant. The bug occured at the last line of the following instruction sequence because ECX was zero: 1E0A7EB2 66 C7 02 0A 00 mov word ptr [edx],0Ah 1E0A7EB7 8B 46 08 mov eax,dword ptr [esi+8] 1E0A7EBA 6A 00 push 0 1E0A7EBC 50 push eax 1E0A7EBD FF 15 B4 31 0C 1E call dword ptr ds:[1E0C31B4h] 1E0A7EC3 89 46 08 mov dword ptr [esi+8],eax 1E0A7EC6 8A 48 FF mov cl,byte ptr [eax-1] 1E0A7EC9 83 C4 08 add esp,8 1E0A7ECC 80 F9 0A cmp cl,0Ah 1E0A7ECF 0F 85 72 FF FF FF jne 1E0A7E47 1E0A7ED5 BB 0A 00 00 00 mov ebx,0Ah 1E0A7EDA 8B 0E mov ecx,dword ptr [esi] 1E0A7EDC 8B 54 24 0C mov edx,dword ptr [esp+0Ch] 1E0A7EE0 8D 04 11 lea eax,[ecx+edx] 1E0A7EE3 89 46 04 mov dword ptr [esi+4],eax 1E0A7EE6 8B 46 08 mov eax,dword ptr [esi+8] 1E0A7EE9 83 E8 02 sub eax,2 1E0A7EEC 3B C1 cmp eax,ecx 1E0A7EEE 72 0F jb 1E0A7EFF 1E0A7EF0 80 38 0D cmp byte ptr [eax],0Dh 1E0A7EF3 75 0A jne 1E0A7EFF 1E0A7EF5 C6 00 0A mov byte ptr [eax],0Ah 1E0A7EF8 40 inc eax 1E0A7EF9 C6 00 00 mov byte ptr [eax],0 1E0A7EFC 89 46 08 mov dword ptr [esi+8],eax 1E0A7EFF 39 5E 14 cmp dword ptr [esi+14h],ebx 1E0A7F02 75 21 jne 1E0A7F25 1E0A7F04 8B 4E 04 mov ecx,dword ptr [esi+4] 1E0A7F07 3B 4E 08 cmp ecx,dword ptr [esi+8] 1E0A7F0A 0F 84 24 FD FF FF je 1E0A7C34 1E0A7F10 0F B6 01 movzx eax,byte ptr [ecx] It may be possible to find the source line related to this bug by searching for this code in the retail python.exe then looking up the address in the map file produced by the compiler (if enabled). I can run the script with a debug version of python.exe. Please send me information about how to download a debug version for Windows. Note: I've tried to search this bug in the bug database, but it's not specific enough to find an exact match. No viruses nor spyware found on my machine using multiple antivirus/antispyware product. No memory errors found in 6 hours. I use LF (UNIX type) line ends on Windows to prevent errors when my scripts copied and edited on a Linux box. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-08-07 13:40 Message: Logged In: YES user_id=31435 Note that it's not legal input: there's a non-ASCII character in line 225, which conflicts with the explicit # -*- coding: ascii -*-" directive near the top of file. Get rid of the non-ASCII character, and it seems to load fine. Current Python HEAD (2.4.2 development) gives a different outcome: File "pycrash.py", line 222 SyntaxError: unknown decode error That's peculiar too, because the offending character is actually on line 225, and because "unknown decode error" is unhelpful. Python 2.3 at least got the line number right: File "pycrash.py", line 225 SyntaxError: unknown decode error The best error report is gotten by deleting the encoding directive instead (using 2.4.1 here): sys:1: DeprecationWarning: Non-ASCII character '\xc1' in file pycrash.py on line 224, but no encoding declared; see http ://www.python.org/peps/pep-0263.html for details Assigning to Martin under the vague recollection that he knows most about the encoding implementation. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-08-04 03:21 Message: Logged In: YES user_id=142612 The bug could be in python.dll, of course. I need a debug version of python.dll. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251631&group_id=5470 From noreply at sourceforge.net Sun Aug 7 22:36:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 07 Aug 2005 13:36:15 -0700 Subject: [ python-Bugs-1248119 ] pdb 'next' does not skip list comprehension Message-ID: Bugs item #1248119, was opened at 2005-07-30 14:12 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&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: Joseph Heled (pepster) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'next' does not skip list comprehension Initial Comment: pdb next command forces you to step over each list element. This seem to be a reincarnation of this old bug. https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523995&group_id=5470 Version: Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-08-07 13:36 Message: Logged In: YES user_id=971153 > The only viable workaround now is to wrap the code in a > temporary function (i.e. lambda : ...). ugly. Would setting a temporary breakpoint (tbreak) on the line after list comprehension be a much simpler workaround? ---------------------------------------------------------------------- Comment By: Joseph Heled (pepster) Date: 2005-07-31 19:25 Message: Logged In: YES user_id=86677 I think this will be wonderfull .... The only viable workaround now is to wrap the code in a temporary function (i.e. lambda : ...). ugly. -Thanks, JOseph ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-31 13:48 Message: Logged In: YES user_id=971153 > you would realize what a serious bummer this is. I agree: this is a definite inconvenience. But I don't see how it is different from having to step through any other loop. However, I think there is a way to solve both problems at once..See below > Giving a 'next N' is nice, but will not be a real solution. > Somethims it is not easy to know how many iterations there > are. And when they are nested etc. Actually, I did not mean "next N" to skip N iterations, what I meant to have 'next N' (or at least next 1) to skip next N lines of code. I.e stop only when line>=line_where_next_N_happened+N is reached... So it seems like we are talking about the same thing...Right? There are a couple of corner cases which would have to be handled, (e.g keeping track of the current frame, etc) Also "next N" would allow to easily skip over any loops (not just list comprehensions), which I think would be a useful feature... What do you think? ---------------------------------------------------------------------- Comment By: Joseph Heled (pepster) Date: 2005-07-30 23:02 Message: Logged In: YES user_id=86677 You probably never use pdb in a real program, otherwise you would realize what a serious bummer this is. Giving a 'next N' is nice, but will not be a real solution. Somethims it is not easy to know how many iterations there are. And when they are nested etc. If you are convinced this is the desired and reasonable behaviour for next (a point of view I don't share), at least have a different command to skip to the next line. I am sorry but I have no idea if this is easy or hard. Thanks, Joseph ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 20:20 Message: Logged In: YES user_id=971153 While this behaviour indeed feels like a bug I'm starting to think that it is not.. Observation1: 'step' should stop at every iteration of a list comprehension Observation2: the only difference between 'step' and 'next' is that 'step' steps into function calls (which is not the case here) So, it seems like 'next' should also stop at every iteration of a list comprehenstion. Ie current behaviour is not a bug... Would supporting a numeric argument for the 'next' command make sense? So that 'next 1' would mean "stop when actual line number increases by at least 1"... ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 17:59 Message: Logged In: YES user_id=971153 A bit more information. I looked into what happens in ceval.c and apparently the current behaviour is intentional.. Looks like this piece of code: else if (frame->f_lasti <= *instr_prev) { /* jumping back in the same line forces a trace event */ result = call_trace(func, obj, frame, PyTrace_LINE, Py_None); } in maybe_call_line_trace() is responsible for the extra "line" events.. Seems like this piece of code was added to fix bug #765624. in ceval.c:2.386 So, should this (1248119) bug be dealt with by skipping extra line events in bdb? Any thoughts? Or am I totally lost? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 17:33 Message: Logged In: YES user_id=971153 I changed bdb.py to print the kind of event it receives as well as as line numbers and here is a session which illustrates the bug... bagira:~/python/dist/src/bug-next1248119> cat t #../python y=[1,2,3,4] x=[ i+1 for i in y] print x bagira:~/python/dist/src/bug-next1248119> ../python -m pdb t event: call; line 1, file event: line; line 1, file event: call; line 2, file t event: line; line 2, file t > /home/ilya/python/dist/src/bug-next1248119/t(2)?() -> y=[1,2,3,4] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] So it appears that the interpreter generates "line" events for every iteration of the loop.. Would this be a bug in the interpreter (and not in pdb/bdb)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&group_id=5470 From noreply at sourceforge.net Sun Aug 7 23:10:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 07 Aug 2005 14:10:38 -0700 Subject: [ python-Bugs-1189330 ] LINKCC incorrect Message-ID: Bugs item #1189330, was opened at 2005-04-25 11:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189330&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: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Christoph Ludwig (cludwig) Assigned to: Nobody/Anonymous (nobody) Summary: LINKCC incorrect Initial Comment: I configured Python 2.4.1 as follows ../Python-2.4.1/configure \ --prefix=/home/cludwig/C++/gcc4.0/Python-2.4.1 \ --with-cxx=/opt/gcc/gcc-4.0.0/bin/g++ --enable-shared \ --enable-unicode --with-signal-module \ --with-universal-newlines --with-doc-strings on a i686-pc-linux-gnu system. make fails when linking the python binariy due to an undefined reference to `__gxx_personality_v0'. In fact, configure set CC= gcc -pthread CXX= /opt/gcc/gcc-4.0.0/bin/g++ -pthread LINKCC= $(PURIFY) $(CC) but the python executable needs to be linked with $(CXX). (Note the `--with-cxx' option in the configure command line.) I did not observe this problem with Python 2.4.0 / gcc 3.4.2. This seems to be a regression w.r.t. PR #569668 that was closed as fixed on 2002-12-03. I can submit config.log and the output of make on request. Regards Christoph ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-07 23:10 Message: Logged In: YES user_id=21627 This is fixed with #1239112. ---------------------------------------------------------------------- Comment By: Christoph Ludwig (cludwig) Date: 2005-05-03 10:29 Message: Logged In: YES user_id=1266029 That depends on how clever the patch is supposed to be. I am going to attach a patch against configure.in (from current CVS) that enforces `LINKCC = $(PURIFY) $(CXX)' if --with-cxx= is passed to configure. My rationale is that a user who specifies --with-cxx wants python to be build with the C++ compiler and therefore won't mind if the executable depends on the C++ runtime library. The previous code in configure.in tried to determine if one can link the executable with the C compiler/linker even if some of the object files were compiled by a C++ compiler. The approach taken seems to be fragile, though: In simple cases g++ 4.0 seems to realize there is no need for the C++ runtime libraries, but in more complex cases it adds a dependency on the C++ runtime anyway. Even if you add a more complex test case to configure.in, how do you know your testcase mirrors the complexity of the python executable and any C++ extension loaded at runtime? I think a proper test would be quite involved whence I prefer the simplistic approach taken by my patch. Do you know a system / use case where one needs to compile python.c with a C++ compiler but needs to avoid the dependency on the C++ runtime? Regards Christoph ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-02 23:13 Message: Logged In: YES user_id=21627 Can you propose a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189330&group_id=5470 From noreply at sourceforge.net Mon Aug 8 09:17:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 08 Aug 2005 00:17:09 -0700 Subject: [ python-Bugs-1251631 ] Python 2.4.1 crashes when importing the attached script Message-ID: Bugs item #1251631, was opened at 2005-08-04 09:18 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251631&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: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Martin v. L?wis (loewis) Summary: Python 2.4.1 crashes when importing the attached script Initial Comment: OS: WinXP Prog. ENG SP1 Python: 2.4.1 MSI installer downloaded from python.org Python crashes or rarely raises MemoryError or SyntaxError when trying to import/execute the script attached. The behaviour changes when some lines are modified, but mostly crashes the python process with a memory access violation. The python process used 4.2Mbytes of system memory when crashed. There were more than 500Mbytes free. Register dump: EAX = 00A8CC61 EBX = 0000000A ECX = 00000000 EDX = 00000000 ESI = 00A10DA0 EDI = 00000022 EIP = 1E0A7F10 ESP = 0021FD98 EBP = 00000222 EFlags = 00000293 Other registers are irrelevant. The bug occured at the last line of the following instruction sequence because ECX was zero: 1E0A7EB2 66 C7 02 0A 00 mov word ptr [edx],0Ah 1E0A7EB7 8B 46 08 mov eax,dword ptr [esi+8] 1E0A7EBA 6A 00 push 0 1E0A7EBC 50 push eax 1E0A7EBD FF 15 B4 31 0C 1E call dword ptr ds:[1E0C31B4h] 1E0A7EC3 89 46 08 mov dword ptr [esi+8],eax 1E0A7EC6 8A 48 FF mov cl,byte ptr [eax-1] 1E0A7EC9 83 C4 08 add esp,8 1E0A7ECC 80 F9 0A cmp cl,0Ah 1E0A7ECF 0F 85 72 FF FF FF jne 1E0A7E47 1E0A7ED5 BB 0A 00 00 00 mov ebx,0Ah 1E0A7EDA 8B 0E mov ecx,dword ptr [esi] 1E0A7EDC 8B 54 24 0C mov edx,dword ptr [esp+0Ch] 1E0A7EE0 8D 04 11 lea eax,[ecx+edx] 1E0A7EE3 89 46 04 mov dword ptr [esi+4],eax 1E0A7EE6 8B 46 08 mov eax,dword ptr [esi+8] 1E0A7EE9 83 E8 02 sub eax,2 1E0A7EEC 3B C1 cmp eax,ecx 1E0A7EEE 72 0F jb 1E0A7EFF 1E0A7EF0 80 38 0D cmp byte ptr [eax],0Dh 1E0A7EF3 75 0A jne 1E0A7EFF 1E0A7EF5 C6 00 0A mov byte ptr [eax],0Ah 1E0A7EF8 40 inc eax 1E0A7EF9 C6 00 00 mov byte ptr [eax],0 1E0A7EFC 89 46 08 mov dword ptr [esi+8],eax 1E0A7EFF 39 5E 14 cmp dword ptr [esi+14h],ebx 1E0A7F02 75 21 jne 1E0A7F25 1E0A7F04 8B 4E 04 mov ecx,dword ptr [esi+4] 1E0A7F07 3B 4E 08 cmp ecx,dword ptr [esi+8] 1E0A7F0A 0F 84 24 FD FF FF je 1E0A7C34 1E0A7F10 0F B6 01 movzx eax,byte ptr [ecx] It may be possible to find the source line related to this bug by searching for this code in the retail python.exe then looking up the address in the map file produced by the compiler (if enabled). I can run the script with a debug version of python.exe. Please send me information about how to download a debug version for Windows. Note: I've tried to search this bug in the bug database, but it's not specific enough to find an exact match. No viruses nor spyware found on my machine using multiple antivirus/antispyware product. No memory errors found in 6 hours. I use LF (UNIX type) line ends on Windows to prevent errors when my scripts copied and edited on a Linux box. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-08-08 09:17 Message: Logged In: YES user_id=89016 The line number problem might be related to http://www.python.org/sf/1178484 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-08-07 19:40 Message: Logged In: YES user_id=31435 Note that it's not legal input: there's a non-ASCII character in line 225, which conflicts with the explicit # -*- coding: ascii -*-" directive near the top of file. Get rid of the non-ASCII character, and it seems to load fine. Current Python HEAD (2.4.2 development) gives a different outcome: File "pycrash.py", line 222 SyntaxError: unknown decode error That's peculiar too, because the offending character is actually on line 225, and because "unknown decode error" is unhelpful. Python 2.3 at least got the line number right: File "pycrash.py", line 225 SyntaxError: unknown decode error The best error report is gotten by deleting the encoding directive instead (using 2.4.1 here): sys:1: DeprecationWarning: Non-ASCII character '\xc1' in file pycrash.py on line 224, but no encoding declared; see http ://www.python.org/peps/pep-0263.html for details Assigning to Martin under the vague recollection that he knows most about the encoding implementation. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-08-04 09:21 Message: Logged In: YES user_id=142612 The bug could be in python.dll, of course. I need a debug version of python.dll. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251631&group_id=5470 From noreply at sourceforge.net Mon Aug 8 10:37:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 08 Aug 2005 01:37:45 -0700 Subject: [ python-Bugs-1099364 ] raw_input() displays wrong unicode prompt Message-ID: Bugs item #1099364, was opened at 2005-01-10 11:33 Message generated for change (Comment added) made by prikryl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099364&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: 6 Submitted By: Petr Prikryl (prikryl) Assigned to: Nobody/Anonymous (nobody) Summary: raw_input() displays wrong unicode prompt Initial Comment: I have observed a problem when running Python 2.4, Windows version (python-2.4.msi) and using raw_input() with unicode prompt string in a console program (ran in the DOS window). I do use the following sitecustomize.py file to set the default encoding in the English Windows 2000 Server: sitecustomize.py ================================= import sys sys.setdefaultencoding('cp1250') ================================= test.py ================================= # -*- coding: cp1250 -*- s = u'string with accented letters (different than this)' print s # OK val = raw_input(s) # s displayed differently (wrong) ================================= See the test.png (captured from screen) and the test.py for the used string -- inside the attached zip file. The "type test.py" (result visible on the captured screen) displays the string definition also wrongly, because the DOS window uses different encoding than cp1250. The print command prints the string correctly, converting the internal unicode string to the encoding that the is defined by the output environment. However, the raw_input() probably does convert the unicode string to the cp1250 and does not do the same (more clever) thing that the print does. I did not use the unicode in older Python (2.3.4), so I do not know what was the behaviour earlier. Could you confirm the bug? Sorry if the bug is well known. Petr ---------------------------------------------------------------------- >Comment By: Petr Prikryl (prikryl) Date: 2005-08-08 10:37 Message: Logged In: YES user_id=771873 As the patch #1214889 that would have solved the problem on lower levels was rejected, the problem should be reopened and the raw_input() internals should be implemented similarly to print. Thanks, Petr ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-28 08:40 Message: Logged In: YES user_id=1188172 You'll have to explicitly encode the unicode string using raw_input(s.encode(sys.stdout.encoding)). As said, this behaviour will change if the patch mentioned is accepted. ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-06-28 07:56 Message: Logged In: YES user_id=771873 Should I understand it that there is no bug, but I do use it incorrectly? I cannot agree that this is expected behaviour. (I am not the only one who found this strange.) Of course, the sys.stdout.encoding is different for a DOS window (cp852) than the default encoding (cp1250). Windows simply behaves this way when working with DOS window (because of legacy DOS applications). I do not complain on behaviour of sys.stdout.write() but on behaviour of raw_input(). The output of raw_input() prompt should be displayed the same way as the print diplays the results to the user. The raw_input() is used for building user interface. Its prompt should not be displayed differently in windows that use different encoding (i.e. DOS console vs. say IDLE console). In other words, how should I use raw_input() to make it working correctly? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 22:34 Message: Logged In: YES user_id=1188172 Actually, your sys.stdout.encoding is set to something different than cp1250, which is why the result of DOS type looks the same as the one of print. This is because print observes sys.stdout.encoding, while sys.stdout.write uses the system default encoding, which is, as you set it, cp1250 and is displayed wrong on the console. Closing this bug, as it is currently expected behaviour (but will perhaps change when patch #1214889 is accepted). ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-04-14 16:34 Message: Logged In: YES user_id=771873 Python 2.4.1 for Windows behaves the same way. Petr ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-04-14 16:26 Message: Logged In: YES user_id=771873 New observation: sys.stdout.write(s) behaves visually on the screen exactly as the raw_input(s) does. So, print does something more when displaying on the screen... Petr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099364&group_id=5470 From noreply at sourceforge.net Mon Aug 8 10:39:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 08 Aug 2005 01:39:38 -0700 Subject: [ python-Bugs-1099364 ] raw_input() displays wrong unicode prompt Message-ID: Bugs item #1099364, was opened at 2005-01-10 11:33 Message generated for change (Settings changed) made by prikryl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099364&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: Invalid Priority: 6 Submitted By: Petr Prikryl (prikryl) Assigned to: Nobody/Anonymous (nobody) Summary: raw_input() displays wrong unicode prompt Initial Comment: I have observed a problem when running Python 2.4, Windows version (python-2.4.msi) and using raw_input() with unicode prompt string in a console program (ran in the DOS window). I do use the following sitecustomize.py file to set the default encoding in the English Windows 2000 Server: sitecustomize.py ================================= import sys sys.setdefaultencoding('cp1250') ================================= test.py ================================= # -*- coding: cp1250 -*- s = u'string with accented letters (different than this)' print s # OK val = raw_input(s) # s displayed differently (wrong) ================================= See the test.png (captured from screen) and the test.py for the used string -- inside the attached zip file. The "type test.py" (result visible on the captured screen) displays the string definition also wrongly, because the DOS window uses different encoding than cp1250. The print command prints the string correctly, converting the internal unicode string to the encoding that the is defined by the output environment. However, the raw_input() probably does convert the unicode string to the cp1250 and does not do the same (more clever) thing that the print does. I did not use the unicode in older Python (2.3.4), so I do not know what was the behaviour earlier. Could you confirm the bug? Sorry if the bug is well known. Petr ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-08-08 10:37 Message: Logged In: YES user_id=771873 As the patch #1214889 that would have solved the problem on lower levels was rejected, the problem should be reopened and the raw_input() internals should be implemented similarly to print. Thanks, Petr ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-28 08:40 Message: Logged In: YES user_id=1188172 You'll have to explicitly encode the unicode string using raw_input(s.encode(sys.stdout.encoding)). As said, this behaviour will change if the patch mentioned is accepted. ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-06-28 07:56 Message: Logged In: YES user_id=771873 Should I understand it that there is no bug, but I do use it incorrectly? I cannot agree that this is expected behaviour. (I am not the only one who found this strange.) Of course, the sys.stdout.encoding is different for a DOS window (cp852) than the default encoding (cp1250). Windows simply behaves this way when working with DOS window (because of legacy DOS applications). I do not complain on behaviour of sys.stdout.write() but on behaviour of raw_input(). The output of raw_input() prompt should be displayed the same way as the print diplays the results to the user. The raw_input() is used for building user interface. Its prompt should not be displayed differently in windows that use different encoding (i.e. DOS console vs. say IDLE console). In other words, how should I use raw_input() to make it working correctly? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 22:34 Message: Logged In: YES user_id=1188172 Actually, your sys.stdout.encoding is set to something different than cp1250, which is why the result of DOS type looks the same as the one of print. This is because print observes sys.stdout.encoding, while sys.stdout.write uses the system default encoding, which is, as you set it, cp1250 and is displayed wrong on the console. Closing this bug, as it is currently expected behaviour (but will perhaps change when patch #1214889 is accepted). ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-04-14 16:34 Message: Logged In: YES user_id=771873 Python 2.4.1 for Windows behaves the same way. Petr ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-04-14 16:26 Message: Logged In: YES user_id=771873 New observation: sys.stdout.write(s) behaves visually on the screen exactly as the raw_input(s) does. So, print does something more when displaying on the screen... Petr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099364&group_id=5470 From noreply at sourceforge.net Mon Aug 8 13:48:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 08 Aug 2005 04:48:01 -0700 Subject: [ python-Bugs-1254125 ] Python interpreter unnecessarily linked against c++ runtime Message-ID: Bugs item #1254125, was opened at 2005-08-08 12:48 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=1254125&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: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zak Kipling (zak-k) Assigned to: Nobody/Anonymous (nobody) Summary: Python interpreter unnecessarily linked against c++ runtime Initial Comment: By default, on an ELF-based Linux system with a working g++, the configure script will choose to build a C++ wrapper for main(). This causes the resulting interpreter executable to be linked against libstdc++. However, the comments in bug #224782 suggest that this is not necessary in order to support C++ extension modules on ELF (unlike a.out). Would it be possible for Modules/ccpython.cc to be used only on those systems that don't correctly support dynamically loading C++ code from C executables? I'm currently seeing this with Python 2.4.1, on a Gentoo ~amd64 system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1254125&group_id=5470 From noreply at sourceforge.net Mon Aug 8 16:56:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 08 Aug 2005 07:56:31 -0700 Subject: [ python-Bugs-1254248 ] parser fails on long non-ascii lines if coding declared Message-ID: Bugs item #1254248, was opened at 2005-08-08 17:56 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=1254248&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Noga (oleg_noga) Assigned to: Nobody/Anonymous (nobody) Summary: parser fails on long non-ascii lines if coding declared Initial Comment: python version: 2.3.5, 2.3.3 os: windows 2000 sp4 Parser fails to read .py file and does one of 1. SyntaxError with broken traceback 2. MemoryError (without traceback) 3. Crush with Access violation 4. Sometimes there is no fail at all and code imported ok Requirements to reproduce 1. Coding must be defined like # -*- coding: Cp1251 -*- if coding not declared it is all ok except warning (pep- 0263). 2. File must have at list one long line (about longer than 256 characters) containing characters with ordinals > 128. 3. Some luck, because sometimes there is no crush. attached parseError.py does MemoryError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1254248&group_id=5470 From noreply at sourceforge.net Mon Aug 8 17:40:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 08 Aug 2005 08:40:16 -0700 Subject: [ python-Bugs-1254248 ] parser fails on long non-ascii lines if coding declared Message-ID: Bugs item #1254248, was opened at 2005-08-08 16:56 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1254248&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.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Oleg Noga (oleg_noga) Assigned to: Nobody/Anonymous (nobody) Summary: parser fails on long non-ascii lines if coding declared Initial Comment: python version: 2.3.5, 2.3.3 os: windows 2000 sp4 Parser fails to read .py file and does one of 1. SyntaxError with broken traceback 2. MemoryError (without traceback) 3. Crush with Access violation 4. Sometimes there is no fail at all and code imported ok Requirements to reproduce 1. Coding must be defined like # -*- coding: Cp1251 -*- if coding not declared it is all ok except warning (pep- 0263). 2. File must have at list one long line (about longer than 256 characters) containing characters with ordinals > 128. 3. Some luck, because sometimes there is no crush. attached parseError.py does MemoryError ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-08-08 17:40 Message: Logged In: YES user_id=89016 This is a duplicate of #1163244. Closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1254248&group_id=5470 From noreply at sourceforge.net Mon Aug 8 19:32:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 08 Aug 2005 10:32:01 -0700 Subject: [ python-Bugs-1254362 ] Docs for list.extend() are incorrect Message-ID: Bugs item #1254362, was opened at 2005-08-08 17:32 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=1254362&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: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Docs for list.extend() are incorrect Initial Comment: 2.3.6.4 Mutable Sequence Types footnote (3) says that list.extend() raises an exception when the argument is not a list object. In fact extend() seems to work with any iterable or iterator. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1254362&group_id=5470 From noreply at sourceforge.net Mon Aug 8 20:02:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 08 Aug 2005 11:02:26 -0700 Subject: [ python-Bugs-1254362 ] Docs for list.extend() are incorrect Message-ID: Bugs item #1254362, was opened at 2005-08-08 19:32 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1254362&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: Closed >Resolution: Out of Date Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Docs for list.extend() are incorrect Initial Comment: 2.3.6.4 Mutable Sequence Types footnote (3) says that list.extend() raises an exception when the argument is not a list object. In fact extend() seems to work with any iterable or iterator. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-08 20:02 Message: Logged In: YES user_id=1188172 This has already been addressed in the Python 2.4.1 documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1254362&group_id=5470 From noreply at sourceforge.net Tue Aug 9 08:34:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 08 Aug 2005 23:34:23 -0700 Subject: [ python-Bugs-1244610 ] 2.4.1 build fails on OpenBSD 3.7 Message-ID: Bugs item #1244610, was opened at 2005-07-25 16:31 Message generated for change (Comment added) made by jp3g You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&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: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 build fails on OpenBSD 3.7 Initial Comment: Python 2.4.1, OpenBSD 3.7, gcc (GCC) 3.3.5 (propolice). I'm including the logs here because they are short. "./configure" printed the following: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------------ ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ------------------------------------------------ ## checking for curses.h... yes This warning was printed for curses.h, ncurses.h, sys/audioio.h, and sys/lock.h. (The reference to "Autoconf documentation" is useless, because autoconf is not used during the configure process, and is not even installed on the system where I was doing the build.) Then: % make gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c In file included from /usr/include/sys/select.h:38, from Include/pyport.h:116, from Include/Python.h:55, from Modules/python.c:3: /usr/include/sys/event.h:53: error: syntax error before "u_int" /usr/include/sys/event.h:55: error: syntax error before "u_short" *** Error code 1 Stop in /usr/src/Python-2.4.1. ---------------------------------------------------------------------- Comment By: johnnie pittman (jp3g) Date: 2005-08-09 06:34 Message: Logged In: YES user_id=1203137 Hey folks, Also seeing this issue on 3.7. Same setup described above. Loewis, not sure about the first part of your comment. If your asking if those header files exist and are available, yes they are (atleast on my system). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 12:43 Message: Logged In: YES user_id=21627 So can you tell us whether there are missing prerequisite headers? One would need to have access to your operating system to resolve this issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 From noreply at sourceforge.net Mon Aug 8 21:08:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 08 Aug 2005 12:08:59 -0700 Subject: [ python-Bugs-1065456 ] pprint.pformat requires __repr__ Message-ID: Bugs item #1065456, was opened at 2004-11-12 16:36 Message generated for change (Comment added) made by cmoad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1065456&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: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Dave Kuhlman (dkuhlman) Assigned to: Nobody/Anonymous (nobody) Summary: pprint.pformat requires __repr__ Initial Comment: Not having a __repr__ attribute seem to cause problems for: pprint.pformat in Python 2.4. This problem goes away when I use a Zope instance for Python 2.3. The error message is generated when I try to access a private workspace in the CPS interface. I inserted a bit of debugging code, and I've attached a file that contains the debugging print-out of the data that caused the error and also the traceback. I'm using: CPS-3.2.1 Zope-2.7.3-0 Python 2.4b2 built from source on Linux. I've attached a file containing a bit of debugging information and also the traceback. Dave ---------------------------------------------------------------------- Comment By: Charles Moad (cmoad) Date: 2005-08-08 14:08 Message: Logged In: YES user_id=705459 This problem affects matplotlib still. Here is a short example: import pprint from matplotlib.transforms import unit_bbox b = unit_bbox() pprint.pformat(b) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-11-15 08:53 Message: Logged In: YES user_id=89016 This should be fixed in pprint.py 1.31 in current CVS. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1065456&group_id=5470 From noreply at sourceforge.net Tue Aug 9 20:30:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 09 Aug 2005 11:30:59 -0700 Subject: [ python-Bugs-1065456 ] pprint.pformat requires __repr__ Message-ID: Bugs item #1065456, was opened at 2004-11-12 22:36 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1065456&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: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Dave Kuhlman (dkuhlman) Assigned to: Nobody/Anonymous (nobody) Summary: pprint.pformat requires __repr__ Initial Comment: Not having a __repr__ attribute seem to cause problems for: pprint.pformat in Python 2.4. This problem goes away when I use a Zope instance for Python 2.3. The error message is generated when I try to access a private workspace in the CPS interface. I inserted a bit of debugging code, and I've attached a file that contains the debugging print-out of the data that caused the error and also the traceback. I'm using: CPS-3.2.1 Zope-2.7.3-0 Python 2.4b2 built from source on Linux. I've attached a file containing a bit of debugging information and also the traceback. Dave ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-08-09 20:30 Message: Logged In: YES user_id=89016 Which version of Python are you using? Can you post a stack trace? ---------------------------------------------------------------------- Comment By: Charles Moad (cmoad) Date: 2005-08-08 21:08 Message: Logged In: YES user_id=705459 This problem affects matplotlib still. Here is a short example: import pprint from matplotlib.transforms import unit_bbox b = unit_bbox() pprint.pformat(b) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-11-15 14:53 Message: Logged In: YES user_id=89016 This should be fixed in pprint.py 1.31 in current CVS. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1065456&group_id=5470 From noreply at sourceforge.net Tue Aug 9 20:34:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 09 Aug 2005 11:34:22 -0700 Subject: [ python-Bugs-1065456 ] pprint.pformat requires __repr__ Message-ID: Bugs item #1065456, was opened at 2004-11-12 16:36 Message generated for change (Comment added) made by cmoad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1065456&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: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Dave Kuhlman (dkuhlman) Assigned to: Nobody/Anonymous (nobody) Summary: pprint.pformat requires __repr__ Initial Comment: Not having a __repr__ attribute seem to cause problems for: pprint.pformat in Python 2.4. This problem goes away when I use a Zope instance for Python 2.3. The error message is generated when I try to access a private workspace in the CPS interface. I inserted a bit of debugging code, and I've attached a file that contains the debugging print-out of the data that caused the error and also the traceback. I'm using: CPS-3.2.1 Zope-2.7.3-0 Python 2.4b2 built from source on Linux. I've attached a file containing a bit of debugging information and also the traceback. Dave ---------------------------------------------------------------------- Comment By: Charles Moad (cmoad) Date: 2005-08-09 13:34 Message: Logged In: YES user_id=705459 This is python 2.4.1 in gentoo linux, compiled from source. Other python 2.4 linux reported the same affect. I don't know how to get a stack trace when python seg faults. We fixed the issue in matplolib's cvs by adding __repr__ support to all the wrapped cxx objects. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-09 13:30 Message: Logged In: YES user_id=89016 Which version of Python are you using? Can you post a stack trace? ---------------------------------------------------------------------- Comment By: Charles Moad (cmoad) Date: 2005-08-08 14:08 Message: Logged In: YES user_id=705459 This problem affects matplotlib still. Here is a short example: import pprint from matplotlib.transforms import unit_bbox b = unit_bbox() pprint.pformat(b) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-11-15 08:53 Message: Logged In: YES user_id=89016 This should be fixed in pprint.py 1.31 in current CVS. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1065456&group_id=5470 From noreply at sourceforge.net Tue Aug 9 20:40:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 09 Aug 2005 11:40:22 -0700 Subject: [ python-Bugs-1244610 ] 2.4.1 build fails on OpenBSD 3.7 Message-ID: Bugs item #1244610, was opened at 2005-07-25 18:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&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: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 build fails on OpenBSD 3.7 Initial Comment: Python 2.4.1, OpenBSD 3.7, gcc (GCC) 3.3.5 (propolice). I'm including the logs here because they are short. "./configure" printed the following: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------------ ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ------------------------------------------------ ## checking for curses.h... yes This warning was printed for curses.h, ncurses.h, sys/audioio.h, and sys/lock.h. (The reference to "Autoconf documentation" is useless, because autoconf is not used during the configure process, and is not even installed on the system where I was doing the build.) Then: % make gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c In file included from /usr/include/sys/select.h:38, from Include/pyport.h:116, from Include/Python.h:55, from Modules/python.c:3: /usr/include/sys/event.h:53: error: syntax error before "u_int" /usr/include/sys/event.h:55: error: syntax error before "u_short" *** Error code 1 Stop in /usr/src/Python-2.4.1. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-09 20:40 Message: Logged In: YES user_id=21627 Can somebody attach a config.log, or reproduce the fragment that deals with the curses.h presence? Does your system require any headers to be included for curses.h to be usable? I.e. if you do #include int main(){} will that program compile, or do you need additional ('prerequisite') headers? ---------------------------------------------------------------------- Comment By: johnnie pittman (jp3g) Date: 2005-08-09 08:34 Message: Logged In: YES user_id=1203137 Hey folks, Also seeing this issue on 3.7. Same setup described above. Loewis, not sure about the first part of your comment. If your asking if those header files exist and are available, yes they are (atleast on my system). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 14:43 Message: Logged In: YES user_id=21627 So can you tell us whether there are missing prerequisite headers? One would need to have access to your operating system to resolve this issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 From noreply at sourceforge.net Tue Aug 9 20:45:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 09 Aug 2005 11:45:38 -0700 Subject: [ python-Bugs-1254125 ] Python interpreter unnecessarily linked against c++ runtime Message-ID: Bugs item #1254125, was opened at 2005-08-08 13:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1254125&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: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zak Kipling (zak-k) Assigned to: Nobody/Anonymous (nobody) Summary: Python interpreter unnecessarily linked against c++ runtime Initial Comment: By default, on an ELF-based Linux system with a working g++, the configure script will choose to build a C++ wrapper for main(). This causes the resulting interpreter executable to be linked against libstdc++. However, the comments in bug #224782 suggest that this is not necessary in order to support C++ extension modules on ELF (unlike a.out). Would it be possible for Modules/ccpython.cc to be used only on those systems that don't correctly support dynamically loading C++ code from C executables? I'm currently seeing this with Python 2.4.1, on a Gentoo ~amd64 system. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-09 20:45 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? If you merely look for a way to prevent linkage with libstdc++, please configure --without-cxx. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1254125&group_id=5470 From noreply at sourceforge.net Tue Aug 9 21:07:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 09 Aug 2005 12:07:13 -0700 Subject: [ python-Bugs-1255218 ] "appropriately decorated" is undefined in MultiFile.push doc Message-ID: Bugs item #1255218, was opened at 2005-08-09 14:07 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=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.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1255218&group_id=5470 From noreply at sourceforge.net Wed Aug 10 02:57:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 09 Aug 2005 17:57:31 -0700 Subject: [ python-Bugs-1183972 ] dest parameter in optparse Message-ID: Bugs item #1183972, was opened at 2005-04-15 15:39 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183972&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.3 Status: Open Resolution: None Priority: 5 Submitted By: ahmado (ahmado) Assigned to: Greg Ward (gward) Summary: dest parameter in optparse Initial Comment: When using the "callback" action, optparse requires that you STILL specify a "dest" parameter, though it is not required or used by the option parser. In fact, if you do not include the "dest" parameter, your options will still work properly, but optparse will generate an exception when calling the "--help" option. Not specifying a "dest" parameter will result in the following Exception when using the default "--help" or "- h" option: File "c:\Python23\lib\optparse.py", line 229, in format_option_strings metavar = option.metavar or option.dest.upper() AttributeError: 'NoneType' object has no attribute 'upper' by simply adding a bogus bug, the --help / -h option works properly even though the dest isn't actually used. ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2005-08-09 20:57 Message: Logged In: YES user_id=14422 ahmado -- please check if this bug is still present in Python 2.4 / Optik 1.5. If you do not respond in a week or two, I will assume that the bug is fixed and close this report. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2005-07-21 22:03 Message: Logged In: YES user_id=14422 I'm pretty sure I fixed this in Optik 1.5 / Python 2.4. Can you 1) verify if the bug is still there in Python 2.4 and 2) if so, supply a small script demonstrating the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183972&group_id=5470 From noreply at sourceforge.net Wed Aug 10 03:15:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 09 Aug 2005 18:15:01 -0700 Subject: [ python-Bugs-1255395 ] float('-inf') Message-ID: Bugs item #1255395, was opened at 2005-08-10 11:15 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=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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1255395&group_id=5470 From noreply at sourceforge.net Wed Aug 10 08:18:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 09 Aug 2005 23:18:03 -0700 Subject: [ python-Bugs-1099364 ] raw_input() displays wrong unicode prompt Message-ID: Bugs item #1099364, was opened at 2005-01-10 11:33 Message generated for change (Settings changed) made by prikryl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099364&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: Works For Me >Priority: 7 Submitted By: Petr Prikryl (prikryl) Assigned to: Nobody/Anonymous (nobody) Summary: raw_input() displays wrong unicode prompt Initial Comment: I have observed a problem when running Python 2.4, Windows version (python-2.4.msi) and using raw_input() with unicode prompt string in a console program (ran in the DOS window). I do use the following sitecustomize.py file to set the default encoding in the English Windows 2000 Server: sitecustomize.py ================================= import sys sys.setdefaultencoding('cp1250') ================================= test.py ================================= # -*- coding: cp1250 -*- s = u'string with accented letters (different than this)' print s # OK val = raw_input(s) # s displayed differently (wrong) ================================= See the test.png (captured from screen) and the test.py for the used string -- inside the attached zip file. The "type test.py" (result visible on the captured screen) displays the string definition also wrongly, because the DOS window uses different encoding than cp1250. The print command prints the string correctly, converting the internal unicode string to the encoding that the is defined by the output environment. However, the raw_input() probably does convert the unicode string to the cp1250 and does not do the same (more clever) thing that the print does. I did not use the unicode in older Python (2.3.4), so I do not know what was the behaviour earlier. Could you confirm the bug? Sorry if the bug is well known. Petr ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-08-08 10:37 Message: Logged In: YES user_id=771873 As the patch #1214889 that would have solved the problem on lower levels was rejected, the problem should be reopened and the raw_input() internals should be implemented similarly to print. Thanks, Petr ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-28 08:40 Message: Logged In: YES user_id=1188172 You'll have to explicitly encode the unicode string using raw_input(s.encode(sys.stdout.encoding)). As said, this behaviour will change if the patch mentioned is accepted. ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-06-28 07:56 Message: Logged In: YES user_id=771873 Should I understand it that there is no bug, but I do use it incorrectly? I cannot agree that this is expected behaviour. (I am not the only one who found this strange.) Of course, the sys.stdout.encoding is different for a DOS window (cp852) than the default encoding (cp1250). Windows simply behaves this way when working with DOS window (because of legacy DOS applications). I do not complain on behaviour of sys.stdout.write() but on behaviour of raw_input(). The output of raw_input() prompt should be displayed the same way as the print diplays the results to the user. The raw_input() is used for building user interface. Its prompt should not be displayed differently in windows that use different encoding (i.e. DOS console vs. say IDLE console). In other words, how should I use raw_input() to make it working correctly? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 22:34 Message: Logged In: YES user_id=1188172 Actually, your sys.stdout.encoding is set to something different than cp1250, which is why the result of DOS type looks the same as the one of print. This is because print observes sys.stdout.encoding, while sys.stdout.write uses the system default encoding, which is, as you set it, cp1250 and is displayed wrong on the console. Closing this bug, as it is currently expected behaviour (but will perhaps change when patch #1214889 is accepted). ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-04-14 16:34 Message: Logged In: YES user_id=771873 Python 2.4.1 for Windows behaves the same way. Petr ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-04-14 16:26 Message: Logged In: YES user_id=771873 New observation: sys.stdout.write(s) behaves visually on the screen exactly as the raw_input(s) does. So, print does something more when displaying on the screen... Petr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099364&group_id=5470 From noreply at sourceforge.net Wed Aug 10 09:07:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 10 Aug 2005 00:07:43 -0700 Subject: [ python-Bugs-1065456 ] pprint.pformat requires __repr__ Message-ID: Bugs item #1065456, was opened at 2004-11-12 22:36 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1065456&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: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Dave Kuhlman (dkuhlman) Assigned to: Nobody/Anonymous (nobody) Summary: pprint.pformat requires __repr__ Initial Comment: Not having a __repr__ attribute seem to cause problems for: pprint.pformat in Python 2.4. This problem goes away when I use a Zope instance for Python 2.3. The error message is generated when I try to access a private workspace in the CPS interface. I inserted a bit of debugging code, and I've attached a file that contains the debugging print-out of the data that caused the error and also the traceback. I'm using: CPS-3.2.1 Zope-2.7.3-0 Python 2.4b2 built from source on Linux. I've attached a file containing a bit of debugging information and also the traceback. Dave ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-08-10 09:07 Message: Logged In: YES user_id=89016 I didn't realize that Python segfaults. I don't think your problem is related to this bug. To get a stacktrace for the segfault you should compile a debug version of Python (via configure --with-pydebug && make), then start gdb with it (gdb ./python) then start the program (run), with gives you a Python prompt, where you can import your failing code. After the segfault you should be back in the debugger, where you can display a stacktrace via the bt command. ---------------------------------------------------------------------- Comment By: Charles Moad (cmoad) Date: 2005-08-09 20:34 Message: Logged In: YES user_id=705459 This is python 2.4.1 in gentoo linux, compiled from source. Other python 2.4 linux reported the same affect. I don't know how to get a stack trace when python seg faults. We fixed the issue in matplolib's cvs by adding __repr__ support to all the wrapped cxx objects. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-09 20:30 Message: Logged In: YES user_id=89016 Which version of Python are you using? Can you post a stack trace? ---------------------------------------------------------------------- Comment By: Charles Moad (cmoad) Date: 2005-08-08 21:08 Message: Logged In: YES user_id=705459 This problem affects matplotlib still. Here is a short example: import pprint from matplotlib.transforms import unit_bbox b = unit_bbox() pprint.pformat(b) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-11-15 14:53 Message: Logged In: YES user_id=89016 This should be fixed in pprint.py 1.31 in current CVS. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1065456&group_id=5470 From noreply at sourceforge.net Wed Aug 10 14:35:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 10 Aug 2005 05:35:57 -0700 Subject: [ python-Bugs-1255395 ] float('-inf') Message-ID: Bugs item #1255395, was opened at 2005-08-10 02:15 Message generated for change (Comment added) made by mwh 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: Open Resolution: None 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: Michael Hudson (mwh) Date: 2005-08-10 13: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 From noreply at sourceforge.net Wed Aug 10 14:49:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 10 Aug 2005 05:49:01 -0700 Subject: [ python-Bugs-1255395 ] float('-inf') Message-ID: Bugs item #1255395, was opened at 2005-08-10 11:15 Message generated for change (Comment added) made by stevenbird 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: Open Resolution: None 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: Steven Bird (stevenbird) Date: 2005-08-10 22: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 22: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 From noreply at sourceforge.net Wed Aug 10 14:56:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 10 Aug 2005 05:56:34 -0700 Subject: [ python-Bugs-1255395 ] float('-inf') Message-ID: Bugs item #1255395, was opened at 2005-08-10 02:15 Message generated for change (Comment added) made by mwh 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: Open Resolution: None 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: Michael Hudson (mwh) Date: 2005-08-10 13: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 13: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 13: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 From noreply at sourceforge.net Wed Aug 10 18:29:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 10 Aug 2005 09:29:17 -0700 Subject: [ python-Bugs-1256010 ] bug in use of __getattribute__ ? Message-ID: Bugs item #1256010, was opened at 2005-08-10 18:29 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=1256010&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: None Status: Open Resolution: None Priority: 5 Submitted By: sylvain ferriol (ninou) Assigned to: Nobody/Anonymous (nobody) Summary: bug in use of __getattribute__ ? Initial Comment: hello, why it do not work: class xx(object): def __getattribute__(self,name): tab = object.__getattribute__(self,'tab') return tab[name] def f(self,a): self.a=a x=xx() xx.tab={'f':xx.f} x.f(3) unbound method f() must be called with xx instance as first argument (got int instance instead) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256010&group_id=5470 From noreply at sourceforge.net Wed Aug 10 19:04:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 10 Aug 2005 10:04:35 -0700 Subject: [ python-Bugs-1256010 ] bug in use of __getattribute__ ? Message-ID: Bugs item #1256010, was opened at 2005-08-10 18:29 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256010&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: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: sylvain ferriol (ninou) Assigned to: Nobody/Anonymous (nobody) Summary: bug in use of __getattribute__ ? Initial Comment: hello, why it do not work: class xx(object): def __getattribute__(self,name): tab = object.__getattribute__(self,'tab') return tab[name] def f(self,a): self.a=a x=xx() xx.tab={'f':xx.f} x.f(3) unbound method f() must be called with xx instance as first argument (got int instance instead) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-10 19:04 Message: Logged In: YES user_id=1188172 This is not a bug. x.f results (via getattribute) in xx.f, which is an "unbound method" (a method of a class that does not belong to a specific instance) and as such has no knowledge of your instance "x". Please post first comp.lang.python in the future, as such things are almost always a programmer's mistake. Closing as Invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256010&group_id=5470 From noreply at sourceforge.net Wed Aug 10 23:29:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 10 Aug 2005 14:29:14 -0700 Subject: [ python-Bugs-1249749 ] Encodings and aliases do not match runtime Message-ID: 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', 'iso_8859_7', 'iso_ir_126', 'elot_928', 'iso_8859_7_1987', 'csisolatingreek', 'greek'] iso8859_8 ['iso_8859_8_1988', 'iso_ir_138', 'iso_8859_8', 'csisolatinhebrew', 'hebrew'] iso8859_9 ['l5', 'iso_8859_9_1989', 'iso_8859_9', 'csisolatin5', 'latin5', 'iso_ir_148'] johab ['cp1361', 'ms1361'] koi8_r ['cskoi8r'] latin_1 ['iso8859', 'csisolatin1', 'latin', 'l1', 'iso_ir_100', 'ibm819', 'cp819', 'iso_8859_1', 'latin1', 'iso_8859_1_1987', '8859'] mac_cyrillic ['maccyrillic'] mac_greek ['macgreek'] mac_iceland ['maciceland'] mac_latin2 ['maccentraleurope', 'maclatin2'] mac_roman ['macroman'] mac_turkish ['macturkish'] mbcs ['dbcs'] ptcp154 ['cp154', 'cyrillic-asian', 'csptcp154', 'pt154'] quopri_codec ['quopri', 'quoted_printable', 'quotedprintable'] rot_13 ['rot13'] shift_jis ['s_jis', 'sjis', 'shiftjis', 'csshiftjis'] shift_jis_2004 ['shiftjis2004', 's_jis_2004', 'sjis_2004'] shift_jisx0213 ['shiftjisx0213', 'sjisx0213', 's_jisx0213'] tactis ['tis260'] tis_620 ['tis620', 'tis_620_2529_1', 'tis_620_2529_0', 'iso_ir_166', 'tis_620_0'] utf_16 ['utf16', 'u16'] utf_16_be ['utf_16be', 'unicodebigunmarked'] utf_16_le ['utf_16le', 'unicodelittleunmarked'] utf_7 ['u7', 'utf7'] utf_8 ['u8', 'utf', 'utf8_ucs4', 'utf8_ucs2', 'utf8'] uu_codec ['uu'] zlib_codec ['zlib', 'zip'] ---------------------------------------------------------------------- >Comment By: liturgist (liturgist) Date: 2005-08-10 16:29 Message: Logged In: YES user_id=197677 The script attached generates two HTML tables in files specified on the command line. usage: encodingaliases.py A static list of codecs in this script is used because the language description is not available in the python runtime. Codecs found in the encodings.aliases.aliases list are added to the list, but will be described as "unknown" encodings. The "bijectiveType" was, like the language descriptions, taken from the current (2.4.1) documentation. It would be much better for the descriptions and "bijective" type settings to come from the runtime. The problem is one of maintenance. Without these available for introspection in the runtime, a new encoding with no alias will never be identified. When it does appear with an alias, it can only be described as "unknown." ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-06 07:49 Message: Logged In: YES user_id=38388 Martin, I don't see any problem with putting the complete list of aliases into the documentation. liturgist, don't worry about hard-coding things into the script. The extra information Martin gave in the table is not likely going to become part of the standard lib, because there's no a lot you can do with it programmatically. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 07:41 Message: Logged In: YES user_id=21627 I would not like to see the documentation contain a complete list of all aliases. The documentation points out that this are "a few common aliases", ie. I selected aliases that people are likely to encounter, and are encouraged to use. I don't think it is useful to produce the table from the code. If you want to know everything in aliases, just look at aliases directly. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-05 12:53 Message: Logged In: YES user_id=197677 I would very much like to produce the doc table from code. However, I have a few questions. It seems that encodings.aliases.aliases is a list of all encodings and not necessarily those supported on all machines. Ie. mbcs on UNIX or embedded systems that might exclude some large character sets to save space. Is this correct? If so, will it remain that way? To find out if an encoding is supported on the current machine, the code should handle the exception generated when codecs.lookup() fails. Right? To generate the table, I need to produce the "Languages" field. This information does not seem to be available from the Python runtime. I would much rather see this information, including a localized version of the string, come from the Python runtime, rather than hardcode it into the script. Is that a possibility? Would it be a better approach? The non-language oriented encodings such as base_64 and rot_13 do not seem to have anything that distinguishes them from human languages. How can these be separated out without hardcoding? Likewise, the non-language encodings have an "Operand type" field which would need to be generated. My feeling is, again, that this should come from the Python runtime and not be hardcoded into the doc generation script. Any suggestions? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 09:47 Message: Logged In: YES user_id=38388 Doc patches are welcome - perhaps you could enhance your script to have the doc table generated from the available codecs and aliases ?! Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249749&group_id=5470 From noreply at sourceforge.net Wed Aug 10 23:59:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 10 Aug 2005 14:59:38 -0700 Subject: [ python-Bugs-1249749 ] Encodings and aliases do not match runtime Message-ID: 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', 'iso_8859_7', 'iso_ir_126', 'elot_928', 'iso_8859_7_1987', 'csisolatingreek', 'greek'] iso8859_8 ['iso_8859_8_1988', 'iso_ir_138', 'iso_8859_8', 'csisolatinhebrew', 'hebrew'] iso8859_9 ['l5', 'iso_8859_9_1989', 'iso_8859_9', 'csisolatin5', 'latin5', 'iso_ir_148'] johab ['cp1361', 'ms1361'] koi8_r ['cskoi8r'] latin_1 ['iso8859', 'csisolatin1', 'latin', 'l1', 'iso_ir_100', 'ibm819', 'cp819', 'iso_8859_1', 'latin1', 'iso_8859_1_1987', '8859'] mac_cyrillic ['maccyrillic'] mac_greek ['macgreek'] mac_iceland ['maciceland'] mac_latin2 ['maccentraleurope', 'maclatin2'] mac_roman ['macroman'] mac_turkish ['macturkish'] mbcs ['dbcs'] ptcp154 ['cp154', 'cyrillic-asian', 'csptcp154', 'pt154'] quopri_codec ['quopri', 'quoted_printable', 'quotedprintable'] rot_13 ['rot13'] shift_jis ['s_jis', 'sjis', 'shiftjis', 'csshiftjis'] shift_jis_2004 ['shiftjis2004', 's_jis_2004', 'sjis_2004'] shift_jisx0213 ['shiftjisx0213', 'sjisx0213', 's_jisx0213'] tactis ['tis260'] tis_620 ['tis620', 'tis_620_2529_1', 'tis_620_2529_0', 'iso_ir_166', 'tis_620_0'] utf_16 ['utf16', 'u16'] utf_16_be ['utf_16be', 'unicodebigunmarked'] utf_16_le ['utf_16le', 'unicodelittleunmarked'] utf_7 ['u7', 'utf7'] utf_8 ['u8', 'utf', 'utf8_ucs4', 'utf8_ucs2', 'utf8'] uu_codec ['uu'] zlib_codec ['zlib', 'zip'] ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-10 23:59 Message: Logged In: YES user_id=21627 I do see a problem with generating these tables automatically. It suggests the reader that the aliases are all equally relevant. However, I bet few people have ever heard of or used, say, 'cspc850multilingual'. As for the actual patch: Please don't generate HTML. Instead, TeX should be generated, as this is the primary source. Also please add a patch to the current TeX file, updating it appropriately. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-10 23:29 Message: Logged In: YES user_id=197677 The script attached generates two HTML tables in files specified on the command line. usage: encodingaliases.py A static list of codecs in this script is used because the language description is not available in the python runtime. Codecs found in the encodings.aliases.aliases list are added to the list, but will be described as "unknown" encodings. The "bijectiveType" was, like the language descriptions, taken from the current (2.4.1) documentation. It would be much better for the descriptions and "bijective" type settings to come from the runtime. The problem is one of maintenance. Without these available for introspection in the runtime, a new encoding with no alias will never be identified. When it does appear with an alias, it can only be described as "unknown." ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-06 14:49 Message: Logged In: YES user_id=38388 Martin, I don't see any problem with putting the complete list of aliases into the documentation. liturgist, don't worry about hard-coding things into the script. The extra information Martin gave in the table is not likely going to become part of the standard lib, because there's no a lot you can do with it programmatically. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 14:41 Message: Logged In: YES user_id=21627 I would not like to see the documentation contain a complete list of all aliases. The documentation points out that this are "a few common aliases", ie. I selected aliases that people are likely to encounter, and are encouraged to use. I don't think it is useful to produce the table from the code. If you want to know everything in aliases, just look at aliases directly. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-05 19:53 Message: Logged In: YES user_id=197677 I would very much like to produce the doc table from code. However, I have a few questions. It seems that encodings.aliases.aliases is a list of all encodings and not necessarily those supported on all machines. Ie. mbcs on UNIX or embedded systems that might exclude some large character sets to save space. Is this correct? If so, will it remain that way? To find out if an encoding is supported on the current machine, the code should handle the exception generated when codecs.lookup() fails. Right? To generate the table, I need to produce the "Languages" field. This information does not seem to be available from the Python runtime. I would much rather see this information, including a localized version of the string, come from the Python runtime, rather than hardcode it into the script. Is that a possibility? Would it be a better approach? The non-language oriented encodings such as base_64 and rot_13 do not seem to have anything that distinguishes them from human languages. How can these be separated out without hardcoding? Likewise, the non-language encodings have an "Operand type" field which would need to be generated. My feeling is, again, that this should come from the Python runtime and not be hardcoded into the doc generation script. Any suggestions? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:47 Message: Logged In: YES user_id=38388 Doc patches are welcome - perhaps you could enhance your script to have the doc table generated from the available codecs and aliases ?! Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249749&group_id=5470 From noreply at sourceforge.net Thu Aug 11 04:54:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 10 Aug 2005 19:54:17 -0700 Subject: [ python-Bugs-1249749 ] Encodings and aliases do not match runtime Message-ID: 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', 'iso_8859_7', 'iso_ir_126', 'elot_928', 'iso_8859_7_1987', 'csisolatingreek', 'greek'] iso8859_8 ['iso_8859_8_1988', 'iso_ir_138', 'iso_8859_8', 'csisolatinhebrew', 'hebrew'] iso8859_9 ['l5', 'iso_8859_9_1989', 'iso_8859_9', 'csisolatin5', 'latin5', 'iso_ir_148'] johab ['cp1361', 'ms1361'] koi8_r ['cskoi8r'] latin_1 ['iso8859', 'csisolatin1', 'latin', 'l1', 'iso_ir_100', 'ibm819', 'cp819', 'iso_8859_1', 'latin1', 'iso_8859_1_1987', '8859'] mac_cyrillic ['maccyrillic'] mac_greek ['macgreek'] mac_iceland ['maciceland'] mac_latin2 ['maccentraleurope', 'maclatin2'] mac_roman ['macroman'] mac_turkish ['macturkish'] mbcs ['dbcs'] ptcp154 ['cp154', 'cyrillic-asian', 'csptcp154', 'pt154'] quopri_codec ['quopri', 'quoted_printable', 'quotedprintable'] rot_13 ['rot13'] shift_jis ['s_jis', 'sjis', 'shiftjis', 'csshiftjis'] shift_jis_2004 ['shiftjis2004', 's_jis_2004', 'sjis_2004'] shift_jisx0213 ['shiftjisx0213', 'sjisx0213', 's_jisx0213'] tactis ['tis260'] tis_620 ['tis620', 'tis_620_2529_1', 'tis_620_2529_0', 'iso_ir_166', 'tis_620_0'] utf_16 ['utf16', 'u16'] utf_16_be ['utf_16be', 'unicodebigunmarked'] utf_16_le ['utf_16le', 'unicodelittleunmarked'] utf_7 ['u7', 'utf7'] utf_8 ['u8', 'utf', 'utf8_ucs4', 'utf8_ucs2', 'utf8'] uu_codec ['uu'] zlib_codec ['zlib', 'zip'] ---------------------------------------------------------------------- >Comment By: liturgist (liturgist) Date: 2005-08-10 21:54 Message: Logged In: YES user_id=197677 For example: there appears to be a codec for iso8859-1, but it has no alias in the encodings.aliases.aliases list and it is not in the current documentation. What is the relationship of iso8859_1 to latin_1? Should iso8859_1 be considered a base codec? When should iso8859_1 be used rather than latin_1? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-10 16:59 Message: Logged In: YES user_id=21627 I do see a problem with generating these tables automatically. It suggests the reader that the aliases are all equally relevant. However, I bet few people have ever heard of or used, say, 'cspc850multilingual'. As for the actual patch: Please don't generate HTML. Instead, TeX should be generated, as this is the primary source. Also please add a patch to the current TeX file, updating it appropriately. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-10 16:29 Message: Logged In: YES user_id=197677 The script attached generates two HTML tables in files specified on the command line. usage: encodingaliases.py A static list of codecs in this script is used because the language description is not available in the python runtime. Codecs found in the encodings.aliases.aliases list are added to the list, but will be described as "unknown" encodings. The "bijectiveType" was, like the language descriptions, taken from the current (2.4.1) documentation. It would be much better for the descriptions and "bijective" type settings to come from the runtime. The problem is one of maintenance. Without these available for introspection in the runtime, a new encoding with no alias will never be identified. When it does appear with an alias, it can only be described as "unknown." ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-06 07:49 Message: Logged In: YES user_id=38388 Martin, I don't see any problem with putting the complete list of aliases into the documentation. liturgist, don't worry about hard-coding things into the script. The extra information Martin gave in the table is not likely going to become part of the standard lib, because there's no a lot you can do with it programmatically. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 07:41 Message: Logged In: YES user_id=21627 I would not like to see the documentation contain a complete list of all aliases. The documentation points out that this are "a few common aliases", ie. I selected aliases that people are likely to encounter, and are encouraged to use. I don't think it is useful to produce the table from the code. If you want to know everything in aliases, just look at aliases directly. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-05 12:53 Message: Logged In: YES user_id=197677 I would very much like to produce the doc table from code. However, I have a few questions. It seems that encodings.aliases.aliases is a list of all encodings and not necessarily those supported on all machines. Ie. mbcs on UNIX or embedded systems that might exclude some large character sets to save space. Is this correct? If so, will it remain that way? To find out if an encoding is supported on the current machine, the code should handle the exception generated when codecs.lookup() fails. Right? To generate the table, I need to produce the "Languages" field. This information does not seem to be available from the Python runtime. I would much rather see this information, including a localized version of the string, come from the Python runtime, rather than hardcode it into the script. Is that a possibility? Would it be a better approach? The non-language oriented encodings such as base_64 and rot_13 do not seem to have anything that distinguishes them from human languages. How can these be separated out without hardcoding? Likewise, the non-language encodings have an "Operand type" field which would need to be generated. My feeling is, again, that this should come from the Python runtime and not be hardcoded into the doc generation script. Any suggestions? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 09:47 Message: Logged In: YES user_id=38388 Doc patches are welcome - perhaps you could enhance your script to have the doc table generated from the available codecs and aliases ?! Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249749&group_id=5470 From noreply at sourceforge.net Thu Aug 11 07:56:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 10 Aug 2005 22:56:42 -0700 Subject: [ python-Bugs-1249749 ] Encodings and aliases do not match runtime Message-ID: 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', 'iso_8859_7', 'iso_ir_126', 'elot_928', 'iso_8859_7_1987', 'csisolatingreek', 'greek'] iso8859_8 ['iso_8859_8_1988', 'iso_ir_138', 'iso_8859_8', 'csisolatinhebrew', 'hebrew'] iso8859_9 ['l5', 'iso_8859_9_1989', 'iso_8859_9', 'csisolatin5', 'latin5', 'iso_ir_148'] johab ['cp1361', 'ms1361'] koi8_r ['cskoi8r'] latin_1 ['iso8859', 'csisolatin1', 'latin', 'l1', 'iso_ir_100', 'ibm819', 'cp819', 'iso_8859_1', 'latin1', 'iso_8859_1_1987', '8859'] mac_cyrillic ['maccyrillic'] mac_greek ['macgreek'] mac_iceland ['maciceland'] mac_latin2 ['maccentraleurope', 'maclatin2'] mac_roman ['macroman'] mac_turkish ['macturkish'] mbcs ['dbcs'] ptcp154 ['cp154', 'cyrillic-asian', 'csptcp154', 'pt154'] quopri_codec ['quopri', 'quoted_printable', 'quotedprintable'] rot_13 ['rot13'] shift_jis ['s_jis', 'sjis', 'shiftjis', 'csshiftjis'] shift_jis_2004 ['shiftjis2004', 's_jis_2004', 'sjis_2004'] shift_jisx0213 ['shiftjisx0213', 'sjisx0213', 's_jisx0213'] tactis ['tis260'] tis_620 ['tis620', 'tis_620_2529_1', 'tis_620_2529_0', 'iso_ir_166', 'tis_620_0'] utf_16 ['utf16', 'u16'] utf_16_be ['utf_16be', 'unicodebigunmarked'] utf_16_le ['utf_16le', 'unicodelittleunmarked'] utf_7 ['u7', 'utf7'] utf_8 ['u8', 'utf', 'utf8_ucs4', 'utf8_ucs2', 'utf8'] uu_codec ['uu'] zlib_codec ['zlib', 'zip'] ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-11 07:56 Message: Logged In: YES user_id=21627 I think the presence of iso8859_1.py is a bug, resulting from automatic generation of these files. The file should be deleted; iso8859-1 should be encoded through the alias to latin-1. Thanks for pointing that out. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-11 04:54 Message: Logged In: YES user_id=197677 For example: there appears to be a codec for iso8859-1, but it has no alias in the encodings.aliases.aliases list and it is not in the current documentation. What is the relationship of iso8859_1 to latin_1? Should iso8859_1 be considered a base codec? When should iso8859_1 be used rather than latin_1? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-10 23:59 Message: Logged In: YES user_id=21627 I do see a problem with generating these tables automatically. It suggests the reader that the aliases are all equally relevant. However, I bet few people have ever heard of or used, say, 'cspc850multilingual'. As for the actual patch: Please don't generate HTML. Instead, TeX should be generated, as this is the primary source. Also please add a patch to the current TeX file, updating it appropriately. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-10 23:29 Message: Logged In: YES user_id=197677 The script attached generates two HTML tables in files specified on the command line. usage: encodingaliases.py A static list of codecs in this script is used because the language description is not available in the python runtime. Codecs found in the encodings.aliases.aliases list are added to the list, but will be described as "unknown" encodings. The "bijectiveType" was, like the language descriptions, taken from the current (2.4.1) documentation. It would be much better for the descriptions and "bijective" type settings to come from the runtime. The problem is one of maintenance. Without these available for introspection in the runtime, a new encoding with no alias will never be identified. When it does appear with an alias, it can only be described as "unknown." ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-06 14:49 Message: Logged In: YES user_id=38388 Martin, I don't see any problem with putting the complete list of aliases into the documentation. liturgist, don't worry about hard-coding things into the script. The extra information Martin gave in the table is not likely going to become part of the standard lib, because there's no a lot you can do with it programmatically. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 14:41 Message: Logged In: YES user_id=21627 I would not like to see the documentation contain a complete list of all aliases. The documentation points out that this are "a few common aliases", ie. I selected aliases that people are likely to encounter, and are encouraged to use. I don't think it is useful to produce the table from the code. If you want to know everything in aliases, just look at aliases directly. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-05 19:53 Message: Logged In: YES user_id=197677 I would very much like to produce the doc table from code. However, I have a few questions. It seems that encodings.aliases.aliases is a list of all encodings and not necessarily those supported on all machines. Ie. mbcs on UNIX or embedded systems that might exclude some large character sets to save space. Is this correct? If so, will it remain that way? To find out if an encoding is supported on the current machine, the code should handle the exception generated when codecs.lookup() fails. Right? To generate the table, I need to produce the "Languages" field. This information does not seem to be available from the Python runtime. I would much rather see this information, including a localized version of the string, come from the Python runtime, rather than hardcode it into the script. Is that a possibility? Would it be a better approach? The non-language oriented encodings such as base_64 and rot_13 do not seem to have anything that distinguishes them from human languages. How can these be separated out without hardcoding? Likewise, the non-language encodings have an "Operand type" field which would need to be generated. My feeling is, again, that this should come from the Python runtime and not be hardcoded into the doc generation script. Any suggestions? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:47 Message: Logged In: YES user_id=38388 Doc patches are welcome - perhaps you could enhance your script to have the doc table generated from the available codecs and aliases ?! Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249749&group_id=5470 From noreply at sourceforge.net Thu Aug 11 09:36:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 00:36:35 -0700 Subject: [ python-Bugs-1251528 ] smtplib and email.py Message-ID: 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 From noreply at sourceforge.net Thu Aug 11 09:40:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 00:40:15 -0700 Subject: [ python-Bugs-1251528 ] smtplib and email.py Message-ID: 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 From noreply at sourceforge.net Thu Aug 11 14:49:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 05:49:37 -0700 Subject: [ python-Bugs-1256669 ] Significant memory leak with PyImport_ReloadModule Message-ID: 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 From noreply at sourceforge.net Thu Aug 11 16:04:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 07:04:29 -0700 Subject: [ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1 Message-ID: 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 patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-18 11:31 Message: Logged In: YES user_id=38388 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. E.g. an ascii codec or latin-1 codec will only ever see standard line ends (not Unicode ones), so the streams .readline() method can be used directly - just like we did before the buffering code was added. 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. 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 ?! About your patch: * Please explain what firstline is supposed to do (preferably in the doc-string). * Why is firstline always set in .readline() ? * Please remove the print repr() * You cannot always be sure that exc has a .start attribute, so you need to accomocate for this situation as well ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-17 18:50 Message: Logged In: YES user_id=89016 It isn't the buffering support per se that breaks the tokenizer. This problem exists even in Python 2.3.x (Simply try the test scripts from http://www.python.org/sf/1089395 with Python 2.3.5 and you'll get a segfault). Applications that rely on len(readline(x)) == x or anything similar are broken anyway. Supporting buffered and unbuffered reading would mean keeping the 2.3 mode of doing things around indefinitely, and we'd loose readline() support for UTF-16 again. BTW, applying Greg Chapman's patch (http://www.python.org/sf/1101726, which fixes the tokenizer) together with this one seems to fix the problem from my previous post. So if you could give http://www.python.org/sf/1101726 a third look, so we can get it into 2.4.2, this would be great. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-17 11:13 Message: Logged In: YES user_id=38388 Walter, I think that instead of trying to get the tokenizer to work with the buffer support in the codecs, you should add a flag that allows to switch off the buffer support in the codecs altogether and then use the unbuffered mode codecs in the tokenizer. I expect that other applications will run into the same kind of problem, so it should be possible to switch off buffering if needed (maybe we should make this the default ?!). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 10:35 Message: Logged In: YES user_id=89016 OK, here is a patch. It adds an additional argument firstline to read(). If this argument is true (i.e. if called from readline()) and a decoding error happens, this error will only be reported if it is in the first line. Otherwise read() will decode up to the error position and put the rest in the bytebuffer. Unfortunately with this patch, I get a segfault with the following stacktrace if I run the test. I don't know if this is related to bug #1089395/patch #1101726. Martin, can you take a look? #0 0x08057ad1 in tok_nextc (tok=0x81ca7b0) at tokenizer.c:719 #1 0x08058558 in tok_get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1075 #2 0x08059331 in PyTokenizer_Get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1466 #3 0x080561b1 in parsetok (tok=0x81ca7b0, g=0x8167980, start=257, err_ret=0xbffff440, flags=0) at parsetok.c:125 #4 0x0805613c in PyParser_ParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", g=0x8167980, start=257, ps1=0x0, ps2=0x0, err_ret=0xbffff440, flags=0) at parsetok.c:90 #5 0x080f3926 in PyParser_SimpleParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, flags=0) at pythonrun.c:1345 #6 0x080f352b in PyRun_FileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, globals=0xb7d62e94, locals=0xb7d62e94, closeit=1, flags=0xbffff544) at pythonrun.c:1239 #7 0x080f22f2 in PyRun_SimpleFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:860 #8 0x080f1b16 in PyRun_AnyFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:664 #9 0x08055e45 in Py_Main (argc=2, argv=0xbffff5f4) at main.c:484 #10 0x08055366 in main (argc=2, argv=0xbffff5f4) at python.c:23 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-07 16:28 Message: Logged In: YES user_id=89016 The reason for this is the new codec buffering code in 2.4: The codec might read and decode more data from the byte stream than is neccessary for decoding one line. I.e. when reading line n, the codec might decode bytes that belong to line n+1, n+2 etc. too. If there's a decoding error in this data, line n gets reported. I don't think there's a simple fix for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 From noreply at sourceforge.net Thu Aug 11 16:31:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 07:31:41 -0700 Subject: [ python-Bugs-1249749 ] Encodings and aliases do not match runtime Message-ID: 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', 'iso_8859_7', 'iso_ir_126', 'elot_928', 'iso_8859_7_1987', 'csisolatingreek', 'greek'] iso8859_8 ['iso_8859_8_1988', 'iso_ir_138', 'iso_8859_8', 'csisolatinhebrew', 'hebrew'] iso8859_9 ['l5', 'iso_8859_9_1989', 'iso_8859_9', 'csisolatin5', 'latin5', 'iso_ir_148'] johab ['cp1361', 'ms1361'] koi8_r ['cskoi8r'] latin_1 ['iso8859', 'csisolatin1', 'latin', 'l1', 'iso_ir_100', 'ibm819', 'cp819', 'iso_8859_1', 'latin1', 'iso_8859_1_1987', '8859'] mac_cyrillic ['maccyrillic'] mac_greek ['macgreek'] mac_iceland ['maciceland'] mac_latin2 ['maccentraleurope', 'maclatin2'] mac_roman ['macroman'] mac_turkish ['macturkish'] mbcs ['dbcs'] ptcp154 ['cp154', 'cyrillic-asian', 'csptcp154', 'pt154'] quopri_codec ['quopri', 'quoted_printable', 'quotedprintable'] rot_13 ['rot13'] shift_jis ['s_jis', 'sjis', 'shiftjis', 'csshiftjis'] shift_jis_2004 ['shiftjis2004', 's_jis_2004', 'sjis_2004'] shift_jisx0213 ['shiftjisx0213', 'sjisx0213', 's_jisx0213'] tactis ['tis260'] tis_620 ['tis620', 'tis_620_2529_1', 'tis_620_2529_0', 'iso_ir_166', 'tis_620_0'] utf_16 ['utf16', 'u16'] utf_16_be ['utf_16be', 'unicodebigunmarked'] utf_16_le ['utf_16le', 'unicodelittleunmarked'] utf_7 ['u7', 'utf7'] utf_8 ['u8', 'utf', 'utf8_ucs4', 'utf8_ucs2', 'utf8'] uu_codec ['uu'] zlib_codec ['zlib', 'zip'] ---------------------------------------------------------------------- >Comment By: liturgist (liturgist) Date: 2005-08-11 09:31 Message: Logged In: YES user_id=197677 If it does not present a problem, making latin_1 and alias for iso8859_1 as the base codec would present the ISO standards as a complete, orthogonal set. The alias would mean that no existing code is broken. Right? Would this approach present any problem? Should this become a separate bug entry? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-11 00:56 Message: Logged In: YES user_id=21627 I think the presence of iso8859_1.py is a bug, resulting from automatic generation of these files. The file should be deleted; iso8859-1 should be encoded through the alias to latin-1. Thanks for pointing that out. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-10 21:54 Message: Logged In: YES user_id=197677 For example: there appears to be a codec for iso8859-1, but it has no alias in the encodings.aliases.aliases list and it is not in the current documentation. What is the relationship of iso8859_1 to latin_1? Should iso8859_1 be considered a base codec? When should iso8859_1 be used rather than latin_1? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-10 16:59 Message: Logged In: YES user_id=21627 I do see a problem with generating these tables automatically. It suggests the reader that the aliases are all equally relevant. However, I bet few people have ever heard of or used, say, 'cspc850multilingual'. As for the actual patch: Please don't generate HTML. Instead, TeX should be generated, as this is the primary source. Also please add a patch to the current TeX file, updating it appropriately. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-10 16:29 Message: Logged In: YES user_id=197677 The script attached generates two HTML tables in files specified on the command line. usage: encodingaliases.py A static list of codecs in this script is used because the language description is not available in the python runtime. Codecs found in the encodings.aliases.aliases list are added to the list, but will be described as "unknown" encodings. The "bijectiveType" was, like the language descriptions, taken from the current (2.4.1) documentation. It would be much better for the descriptions and "bijective" type settings to come from the runtime. The problem is one of maintenance. Without these available for introspection in the runtime, a new encoding with no alias will never be identified. When it does appear with an alias, it can only be described as "unknown." ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-06 07:49 Message: Logged In: YES user_id=38388 Martin, I don't see any problem with putting the complete list of aliases into the documentation. liturgist, don't worry about hard-coding things into the script. The extra information Martin gave in the table is not likely going to become part of the standard lib, because there's no a lot you can do with it programmatically. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 07:41 Message: Logged In: YES user_id=21627 I would not like to see the documentation contain a complete list of all aliases. The documentation points out that this are "a few common aliases", ie. I selected aliases that people are likely to encounter, and are encouraged to use. I don't think it is useful to produce the table from the code. If you want to know everything in aliases, just look at aliases directly. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-05 12:53 Message: Logged In: YES user_id=197677 I would very much like to produce the doc table from code. However, I have a few questions. It seems that encodings.aliases.aliases is a list of all encodings and not necessarily those supported on all machines. Ie. mbcs on UNIX or embedded systems that might exclude some large character sets to save space. Is this correct? If so, will it remain that way? To find out if an encoding is supported on the current machine, the code should handle the exception generated when codecs.lookup() fails. Right? To generate the table, I need to produce the "Languages" field. This information does not seem to be available from the Python runtime. I would much rather see this information, including a localized version of the string, come from the Python runtime, rather than hardcode it into the script. Is that a possibility? Would it be a better approach? The non-language oriented encodings such as base_64 and rot_13 do not seem to have anything that distinguishes them from human languages. How can these be separated out without hardcoding? Likewise, the non-language encodings have an "Operand type" field which would need to be generated. My feeling is, again, that this should come from the Python runtime and not be hardcoded into the doc generation script. Any suggestions? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 09:47 Message: Logged In: YES user_id=38388 Doc patches are welcome - perhaps you could enhance your script to have the doc table generated from the available codecs and aliases ?! Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249749&group_id=5470 From noreply at sourceforge.net Thu Aug 11 17:08:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 08:08:02 -0700 Subject: [ python-Bugs-1256786 ] slice object uses -1 as exclusive end-bound Message-ID: 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 From noreply at sourceforge.net Thu Aug 11 17:22:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 08:22:27 -0700 Subject: [ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1 Message-ID: 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 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 patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-18 11:31 Message: Logged In: YES user_id=38388 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. E.g. an ascii codec or latin-1 codec will only ever see standard line ends (not Unicode ones), so the streams .readline() method can be used directly - just like we did before the buffering code was added. 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. 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 ?! About your patch: * Please explain what firstline is supposed to do (preferably in the doc-string). * Why is firstline always set in .readline() ? * Please remove the print repr() * You cannot always be sure that exc has a .start attribute, so you need to accomocate for this situation as well ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-17 18:50 Message: Logged In: YES user_id=89016 It isn't the buffering support per se that breaks the tokenizer. This problem exists even in Python 2.3.x (Simply try the test scripts from http://www.python.org/sf/1089395 with Python 2.3.5 and you'll get a segfault). Applications that rely on len(readline(x)) == x or anything similar are broken anyway. Supporting buffered and unbuffered reading would mean keeping the 2.3 mode of doing things around indefinitely, and we'd loose readline() support for UTF-16 again. BTW, applying Greg Chapman's patch (http://www.python.org/sf/1101726, which fixes the tokenizer) together with this one seems to fix the problem from my previous post. So if you could give http://www.python.org/sf/1101726 a third look, so we can get it into 2.4.2, this would be great. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-17 11:13 Message: Logged In: YES user_id=38388 Walter, I think that instead of trying to get the tokenizer to work with the buffer support in the codecs, you should add a flag that allows to switch off the buffer support in the codecs altogether and then use the unbuffered mode codecs in the tokenizer. I expect that other applications will run into the same kind of problem, so it should be possible to switch off buffering if needed (maybe we should make this the default ?!). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 10:35 Message: Logged In: YES user_id=89016 OK, here is a patch. It adds an additional argument firstline to read(). If this argument is true (i.e. if called from readline()) and a decoding error happens, this error will only be reported if it is in the first line. Otherwise read() will decode up to the error position and put the rest in the bytebuffer. Unfortunately with this patch, I get a segfault with the following stacktrace if I run the test. I don't know if this is related to bug #1089395/patch #1101726. Martin, can you take a look? #0 0x08057ad1 in tok_nextc (tok=0x81ca7b0) at tokenizer.c:719 #1 0x08058558 in tok_get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1075 #2 0x08059331 in PyTokenizer_Get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1466 #3 0x080561b1 in parsetok (tok=0x81ca7b0, g=0x8167980, start=257, err_ret=0xbffff440, flags=0) at parsetok.c:125 #4 0x0805613c in PyParser_ParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", g=0x8167980, start=257, ps1=0x0, ps2=0x0, err_ret=0xbffff440, flags=0) at parsetok.c:90 #5 0x080f3926 in PyParser_SimpleParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, flags=0) at pythonrun.c:1345 #6 0x080f352b in PyRun_FileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, globals=0xb7d62e94, locals=0xb7d62e94, closeit=1, flags=0xbffff544) at pythonrun.c:1239 #7 0x080f22f2 in PyRun_SimpleFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:860 #8 0x080f1b16 in PyRun_AnyFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:664 #9 0x08055e45 in Py_Main (argc=2, argv=0xbffff5f4) at main.c:484 #10 0x08055366 in main (argc=2, argv=0xbffff5f4) at python.c:23 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-07 16:28 Message: Logged In: YES user_id=89016 The reason for this is the new codec buffering code in 2.4: The codec might read and decode more data from the byte stream than is neccessary for decoding one line. I.e. when reading line n, the codec might decode bytes that belong to line n+1, n+2 etc. too. If there's a decoding error in this data, line n gets reported. I don't think there's a simple fix for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 From noreply at sourceforge.net Thu Aug 11 19:11:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 10:11:35 -0700 Subject: [ python-Bugs-1255218 ] "appropriately decorated" is undefined in MultiFile.push doc Message-ID: 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 From noreply at sourceforge.net Thu Aug 11 19:33:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 10:33:09 -0700 Subject: [ python-Bugs-1255395 ] float('-inf') Message-ID: 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 From noreply at sourceforge.net Thu Aug 11 19:43:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 10:43:20 -0700 Subject: [ python-Bugs-1249615 ] isinstance() fails depending on how modules imported Message-ID: 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 clearly there may be subtle failure modes - for example, exception handling may use isinstance() internally to see if an exception is an instance of a given class. I've modified the code and added some more testing which shows clearly that it's not the class object itself which is the problem, but when you have a class method which accepts an instance of the class as a parameter. Any test of the class of that parameter will fail if the first instance is created in one module and the second instance is created in another module, and they import the class module differently. Note that it's not restricted to isinstance() - checking __class__ fails as well. Also, in both of the modules that import the class module, isinstance() checking succeeds. There is a false sense of security that isinstance() checking will be OK. Modifed code attached. Hugh ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-02 05:19 Message: Logged In: YES user_id=1188172 This has bitten me too at one time. When you import a module from a package starting from different sys.path entries, you will end up with two different modules in sys.modules. This seems to be intended behaviour, but I don't know enough about it to close this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249615&group_id=5470 From noreply at sourceforge.net Thu Aug 11 20:19:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 11:19:11 -0700 Subject: [ python-Bugs-1066546 ] test_pwd fails on 64bit system (Opteron) Message-ID: 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 (bhcompile at dolly.build.redhat.com) (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.000000000 -0500 +++ Python-2.4/Modules/grpmodule.c 2005-08-11 13:36:48.000000000 -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.000000000 -0500 +++ Python-2.4/Modules/pwdmodule.c 2005-08-11 13:36:27.000000000 -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 (bhcompile at thor.perf.redhat.com) (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 user_id=358087 1. How do I find the largest user id? 2. It's 4294967294 3. Can't attach etc/password since it's a company machine (IT will kill me :-) However there is a similar line for nobody with 65534 The hardware is 4 CPU with 16GB of memory. OS is: Red Hat Enterprise Linux AS release 3 (Taroon Update 3) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-11-16 19:58 Message: Logged In: YES user_id=33168 I just tested this on an opteron and it ran ok, so this problem isn't necessarily opteron/64-bit specific. What is the largest user id on the system? What is the value of pw_uid that is causing a problem? Can you attach your /etc/passwd file? If so, you may want to change any user info. I have: nobody:x:65534:65534:nobody:/:/bin/false I tried adding another nobody with a larger uid, but did not have any problems with the test. This is on a gentoo system. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-11-15 03:36 Message: Logged In: YES user_id=358087 Ran with -v: $ ./python Lib/test/test_pwd.py -v test_errors (__main__.PwdTest) ... ok test_values (__main__.PwdTest) ... ERROR ====================================================================== ERROR: test_values (__main__.PwdTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "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 ---------------------------------------------------------------------- Ran 2 tests in 0.480s FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_pwd.py", line 92, in ? test_main() File "Lib/test/test_pwd.py", line 89, in test_main test_support.run_unittest(PwdTest) File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py", line 290, in run_unitt est run_suite(suite, testclass) File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&group_id=5470 From noreply at sourceforge.net Thu Aug 11 20:21:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 11:21:07 -0700 Subject: [ python-Bugs-1255395 ] float('-inf') Message-ID: 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 From noreply at sourceforge.net Thu Aug 11 20:33:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 11:33:55 -0700 Subject: [ python-Bugs-1250389 ] The -m option to python does not search zip files Message-ID: 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 From noreply at sourceforge.net Thu Aug 11 21:11:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 12:11:52 -0700 Subject: [ python-Bugs-1232947 ] non-admin install may fail (win xp pro) Message-ID: 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 From noreply at sourceforge.net Thu Aug 11 21:14:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 12:14:08 -0700 Subject: [ python-Bugs-1232947 ] non-admin install may fail (win xp pro) Message-ID: 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. 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 From noreply at sourceforge.net Thu Aug 11 22:58:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 13:58:23 -0700 Subject: [ python-Bugs-1255218 ] "appropriately decorated" is undefined in MultiFile.push doc Message-ID: 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 From noreply at sourceforge.net Fri Aug 12 00:10:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 15:10:12 -0700 Subject: [ python-Bugs-1249749 ] Encodings and aliases do not match runtime Message-ID: 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', 'iso_8859_7', 'iso_ir_126', 'elot_928', 'iso_8859_7_1987', 'csisolatingreek', 'greek'] iso8859_8 ['iso_8859_8_1988', 'iso_ir_138', 'iso_8859_8', 'csisolatinhebrew', 'hebrew'] iso8859_9 ['l5', 'iso_8859_9_1989', 'iso_8859_9', 'csisolatin5', 'latin5', 'iso_ir_148'] johab ['cp1361', 'ms1361'] koi8_r ['cskoi8r'] latin_1 ['iso8859', 'csisolatin1', 'latin', 'l1', 'iso_ir_100', 'ibm819', 'cp819', 'iso_8859_1', 'latin1', 'iso_8859_1_1987', '8859'] mac_cyrillic ['maccyrillic'] mac_greek ['macgreek'] mac_iceland ['maciceland'] mac_latin2 ['maccentraleurope', 'maclatin2'] mac_roman ['macroman'] mac_turkish ['macturkish'] mbcs ['dbcs'] ptcp154 ['cp154', 'cyrillic-asian', 'csptcp154', 'pt154'] quopri_codec ['quopri', 'quoted_printable', 'quotedprintable'] rot_13 ['rot13'] shift_jis ['s_jis', 'sjis', 'shiftjis', 'csshiftjis'] shift_jis_2004 ['shiftjis2004', 's_jis_2004', 'sjis_2004'] shift_jisx0213 ['shiftjisx0213', 'sjisx0213', 's_jisx0213'] tactis ['tis260'] tis_620 ['tis620', 'tis_620_2529_1', 'tis_620_2529_0', 'iso_ir_166', 'tis_620_0'] utf_16 ['utf16', 'u16'] utf_16_be ['utf_16be', 'unicodebigunmarked'] utf_16_le ['utf_16le', 'unicodelittleunmarked'] utf_7 ['u7', 'utf7'] utf_8 ['u8', 'utf', 'utf8_ucs4', 'utf8_ucs2', 'utf8'] uu_codec ['uu'] zlib_codec ['zlib', 'zip'] ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-12 00:10 Message: Logged In: YES user_id=21627 It does present a problem: the latin-1 codec is faster than the iso8859-1 codec, as it is a special case in C (employin the fact that Latin-1 and Unicode share the first 256 code points). So I think the iso8859-1 should be dropped. But, as you guess, this is an issue independent of the documentation issue at hand, and should be reported (and resolved) separately. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-11 16:31 Message: Logged In: YES user_id=197677 If it does not present a problem, making latin_1 and alias for iso8859_1 as the base codec would present the ISO standards as a complete, orthogonal set. The alias would mean that no existing code is broken. Right? Would this approach present any problem? Should this become a separate bug entry? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-11 07:56 Message: Logged In: YES user_id=21627 I think the presence of iso8859_1.py is a bug, resulting from automatic generation of these files. The file should be deleted; iso8859-1 should be encoded through the alias to latin-1. Thanks for pointing that out. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-11 04:54 Message: Logged In: YES user_id=197677 For example: there appears to be a codec for iso8859-1, but it has no alias in the encodings.aliases.aliases list and it is not in the current documentation. What is the relationship of iso8859_1 to latin_1? Should iso8859_1 be considered a base codec? When should iso8859_1 be used rather than latin_1? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-10 23:59 Message: Logged In: YES user_id=21627 I do see a problem with generating these tables automatically. It suggests the reader that the aliases are all equally relevant. However, I bet few people have ever heard of or used, say, 'cspc850multilingual'. As for the actual patch: Please don't generate HTML. Instead, TeX should be generated, as this is the primary source. Also please add a patch to the current TeX file, updating it appropriately. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-10 23:29 Message: Logged In: YES user_id=197677 The script attached generates two HTML tables in files specified on the command line. usage: encodingaliases.py A static list of codecs in this script is used because the language description is not available in the python runtime. Codecs found in the encodings.aliases.aliases list are added to the list, but will be described as "unknown" encodings. The "bijectiveType" was, like the language descriptions, taken from the current (2.4.1) documentation. It would be much better for the descriptions and "bijective" type settings to come from the runtime. The problem is one of maintenance. Without these available for introspection in the runtime, a new encoding with no alias will never be identified. When it does appear with an alias, it can only be described as "unknown." ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-06 14:49 Message: Logged In: YES user_id=38388 Martin, I don't see any problem with putting the complete list of aliases into the documentation. liturgist, don't worry about hard-coding things into the script. The extra information Martin gave in the table is not likely going to become part of the standard lib, because there's no a lot you can do with it programmatically. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 14:41 Message: Logged In: YES user_id=21627 I would not like to see the documentation contain a complete list of all aliases. The documentation points out that this are "a few common aliases", ie. I selected aliases that people are likely to encounter, and are encouraged to use. I don't think it is useful to produce the table from the code. If you want to know everything in aliases, just look at aliases directly. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-05 19:53 Message: Logged In: YES user_id=197677 I would very much like to produce the doc table from code. However, I have a few questions. It seems that encodings.aliases.aliases is a list of all encodings and not necessarily those supported on all machines. Ie. mbcs on UNIX or embedded systems that might exclude some large character sets to save space. Is this correct? If so, will it remain that way? To find out if an encoding is supported on the current machine, the code should handle the exception generated when codecs.lookup() fails. Right? To generate the table, I need to produce the "Languages" field. This information does not seem to be available from the Python runtime. I would much rather see this information, including a localized version of the string, come from the Python runtime, rather than hardcode it into the script. Is that a possibility? Would it be a better approach? The non-language oriented encodings such as base_64 and rot_13 do not seem to have anything that distinguishes them from human languages. How can these be separated out without hardcoding? Likewise, the non-language encodings have an "Operand type" field which would need to be generated. My feeling is, again, that this should come from the Python runtime and not be hardcoded into the doc generation script. Any suggestions? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:47 Message: Logged In: YES user_id=38388 Doc patches are welcome - perhaps you could enhance your script to have the doc table generated from the available codecs and aliases ?! Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249749&group_id=5470 From noreply at sourceforge.net Fri Aug 12 01:17:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 16:17:09 -0700 Subject: [ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1 Message-ID: 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 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 patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-18 11:31 Message: Logged In: YES user_id=38388 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. E.g. an ascii codec or latin-1 codec will only ever see standard line ends (not Unicode ones), so the streams .readline() method can be used directly - just like we did before the buffering code was added. 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. 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 ?! About your patch: * Please explain what firstline is supposed to do (preferably in the doc-string). * Why is firstline always set in .readline() ? * Please remove the print repr() * You cannot always be sure that exc has a .start attribute, so you need to accomocate for this situation as well ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-17 18:50 Message: Logged In: YES user_id=89016 It isn't the buffering support per se that breaks the tokenizer. This problem exists even in Python 2.3.x (Simply try the test scripts from http://www.python.org/sf/1089395 with Python 2.3.5 and you'll get a segfault). Applications that rely on len(readline(x)) == x or anything similar are broken anyway. Supporting buffered and unbuffered reading would mean keeping the 2.3 mode of doing things around indefinitely, and we'd loose readline() support for UTF-16 again. BTW, applying Greg Chapman's patch (http://www.python.org/sf/1101726, which fixes the tokenizer) together with this one seems to fix the problem from my previous post. So if you could give http://www.python.org/sf/1101726 a third look, so we can get it into 2.4.2, this would be great. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-17 11:13 Message: Logged In: YES user_id=38388 Walter, I think that instead of trying to get the tokenizer to work with the buffer support in the codecs, you should add a flag that allows to switch off the buffer support in the codecs altogether and then use the unbuffered mode codecs in the tokenizer. I expect that other applications will run into the same kind of problem, so it should be possible to switch off buffering if needed (maybe we should make this the default ?!). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 10:35 Message: Logged In: YES user_id=89016 OK, here is a patch. It adds an additional argument firstline to read(). If this argument is true (i.e. if called from readline()) and a decoding error happens, this error will only be reported if it is in the first line. Otherwise read() will decode up to the error position and put the rest in the bytebuffer. Unfortunately with this patch, I get a segfault with the following stacktrace if I run the test. I don't know if this is related to bug #1089395/patch #1101726. Martin, can you take a look? #0 0x08057ad1 in tok_nextc (tok=0x81ca7b0) at tokenizer.c:719 #1 0x08058558 in tok_get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1075 #2 0x08059331 in PyTokenizer_Get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1466 #3 0x080561b1 in parsetok (tok=0x81ca7b0, g=0x8167980, start=257, err_ret=0xbffff440, flags=0) at parsetok.c:125 #4 0x0805613c in PyParser_ParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", g=0x8167980, start=257, ps1=0x0, ps2=0x0, err_ret=0xbffff440, flags=0) at parsetok.c:90 #5 0x080f3926 in PyParser_SimpleParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, flags=0) at pythonrun.c:1345 #6 0x080f352b in PyRun_FileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, globals=0xb7d62e94, locals=0xb7d62e94, closeit=1, flags=0xbffff544) at pythonrun.c:1239 #7 0x080f22f2 in PyRun_SimpleFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:860 #8 0x080f1b16 in PyRun_AnyFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:664 #9 0x08055e45 in Py_Main (argc=2, argv=0xbffff5f4) at main.c:484 #10 0x08055366 in main (argc=2, argv=0xbffff5f4) at python.c:23 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-07 16:28 Message: Logged In: YES user_id=89016 The reason for this is the new codec buffering code in 2.4: The codec might read and decode more data from the byte stream than is neccessary for decoding one line. I.e. when reading line n, the codec might decode bytes that belong to line n+1, n+2 etc. too. If there's a decoding error in this data, line n gets reported. I don't think there's a simple fix for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 From noreply at sourceforge.net Fri Aug 12 04:22:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 19:22:56 -0700 Subject: [ python-Bugs-1208304 ] urllib2's urlopen() method causes a memory leak Message-ID: 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 From noreply at sourceforge.net Fri Aug 12 04:26:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Aug 2005 19:26:29 -0700 Subject: [ python-Bugs-1257255 ] tarfile local name is local, should be abspath Message-ID: 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 From noreply at sourceforge.net Fri Aug 12 14:22:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 05:22:29 -0700 Subject: [ python-Bugs-1257525 ] Encodings iso8859_1 and latin_1 are redundant Message-ID: Bugs item #1257525, was opened at 2005-08-12 07: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=1257525&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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Encodings iso8859_1 and latin_1 are redundant Initial Comment: ./lib/encodings contains both: iso8859_1.py latin_1.py Only one should be present. Martin says that latin_1 is faster. Using the 'iso' name would correlate better with the other ISO encodings provided. If the latin_1 code is faster, then it should be in the iso8859_1.py file. If an automated process produces the 'iso*' encodings, then it should either produce the faster code or stop producing iso8859_1. Regardless, one of the files should be removed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&group_id=5470 From noreply at sourceforge.net Fri Aug 12 14:49:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 05:49:05 -0700 Subject: [ python-Bugs-1257525 ] Encodings iso8859_1 and latin_1 are redundant Message-ID: Bugs item #1257525, was opened at 2005-08-12 14:22 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Encodings iso8859_1 and latin_1 are redundant Initial Comment: ./lib/encodings contains both: iso8859_1.py latin_1.py Only one should be present. Martin says that latin_1 is faster. Using the 'iso' name would correlate better with the other ISO encodings provided. If the latin_1 code is faster, then it should be in the iso8859_1.py file. If an automated process produces the 'iso*' encodings, then it should either produce the faster code or stop producing iso8859_1. Regardless, one of the files should be removed. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-12 14:49 Message: Logged In: YES user_id=38388 Good point. The iso8859_1.py codec should be removed and added as alias to latin-1. Martin is right: the latin-1 codec is not only faster, but the Unicode integration code also has a lot of short-cuts for the "latin-1" encoding, so overall performance is better if you use that name for the encoding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&group_id=5470 From noreply at sourceforge.net Fri Aug 12 15:02:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 06:02:55 -0700 Subject: [ python-Bugs-1256786 ] slice object uses -1 as exclusive end-bound Message-ID: Bugs item #1256786, was opened at 2005-08-11 16:08 Message generated for change (Comment added) made by mwh 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: Michael Hudson (mwh) 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. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-08-12 14:02 Message: Logged In: YES user_id=6656 This is clearly in my area. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256786&group_id=5470 From noreply at sourceforge.net Fri Aug 12 15:12:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 06:12:40 -0700 Subject: [ python-Bugs-1257525 ] Encodings iso8859_1 and latin_1 are redundant Message-ID: Bugs item #1257525, was opened at 2005-08-12 07:22 Message generated for change (Comment added) made by liturgist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Encodings iso8859_1 and latin_1 are redundant Initial Comment: ./lib/encodings contains both: iso8859_1.py latin_1.py Only one should be present. Martin says that latin_1 is faster. Using the 'iso' name would correlate better with the other ISO encodings provided. If the latin_1 code is faster, then it should be in the iso8859_1.py file. If an automated process produces the 'iso*' encodings, then it should either produce the faster code or stop producing iso8859_1. Regardless, one of the files should be removed. ---------------------------------------------------------------------- >Comment By: liturgist (liturgist) Date: 2005-08-12 08:12 Message: Logged In: YES user_id=197677 Ok. How about if we specify iso8859_1 as "(see latin_1)" in the documentation? The code will work the same regardless of which encoding name the developer uses. Right? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-12 07:49 Message: Logged In: YES user_id=38388 Good point. The iso8859_1.py codec should be removed and added as alias to latin-1. Martin is right: the latin-1 codec is not only faster, but the Unicode integration code also has a lot of short-cuts for the "latin-1" encoding, so overall performance is better if you use that name for the encoding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&group_id=5470 From noreply at sourceforge.net Fri Aug 12 15:48:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 06:48:26 -0700 Subject: [ python-Bugs-1194328 ] Reading from a killed shell script with popen* under linux Message-ID: Bugs item #1194328, was opened at 2005-05-03 09:44 Message generated for change (Comment added) made by boukthor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194328&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Vinz (boukthor) Assigned to: Nobody/Anonymous (nobody) Summary: Reading from a killed shell script with popen* under linux Initial Comment: These are problems I've run into under linux (Mandrake 10.0 through 2006.0, Debian 3.1 and Gentoo) with python versions ranging from 2.3.3 to 2.4: If you run this: import os pout = os.popen("/bin/sleep 999") print pout.read() print pout.close() and kill the "sleep", you get the desired behaviour: the read returns an empty string when the process gets killed and the close returns the killing signal. However, if you put the "sleep" command in a shell script, for example this simple "/tmp/test.sh": #!/bin/sh sleep 999 and run the script through popen (or one of the popen* method of the os and popen2 module) import os pout = os.popen("/tmp/test.sh") print pout.read() print pout.close() then kill the sh running "test.sh", the read never returns and the shell remains as a zombie. You can get some strange behaviour with the Popen* classes too (whether bypassing the shell intervention or not). For example, run this (and kill the subshell): import popen2 sub = popen2.Popen3("/tmp/test.sh") print sub.wait() print sub.fromchild.read() this time the wait correctly returns the signal that killed the shell and removes it from the process table, but the read hangs again. As an added oddity, if you run the popen command from an interactive prompt and raise a KeyboardInterrupt by pressing Ctrl-C before trying to read from the pipe, you kill the subprocess with the SIGINT... I have a final suggestion: if you try reading the output of a popen* method with a "for" statement like this: import os pout = os.popen("for i in $(seq 1 10); do echo $i; sleep 1; done") for l in pout: print l, it waits for the subprocess to complete before going into the loop. To get the output as it is piped, you have to use the poll method of the Popen* classes (which is not available under OSes other than Unix): sub = popen2.Popen3("for i in $(seq 1 10); do echo $i; sleep 1; done") while (-1 == sub.poll()): print sub.fromchild.readline() I don't know if this last behaviour can be fixed or not but I'd suggest some mention of this in the manual if it can't. ---------------------------------------------------------------------- >Comment By: Vinz (boukthor) Date: 2005-08-12 13:48 Message: Logged In: YES user_id=638508 The report #1180160 was only loosely related to the above problem. In fact it is probably closer to the following : 761888 popen2.Popen3 and popen2.Popen4 leaks filedescriptors 892939 Race condition in popen2 998246 Popen3.poll race condition 1183780 Popen4 wait() fails sporadically with threads NB : This bug is very incapacitating for me since I can't figure any workaround and though I understand that developers may have other priorities, I'd appreciate some acknowledgement that somebody at least read this report... ---------------------------------------------------------------------- Comment By: Vinz (boukthor) Date: 2005-05-03 09:49 Message: Logged In: YES user_id=638508 Oops, just saw the report #1180160. I missed it because I searched for popen, not Popen before posting. My bad. I'll cross-reference the two. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194328&group_id=5470 From noreply at sourceforge.net Fri Aug 12 16:01:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 07:01:39 -0700 Subject: [ python-Bugs-1257525 ] Encodings iso8859_1 and latin_1 are redundant Message-ID: Bugs item #1257525, was opened at 2005-08-12 07:22 Message generated for change (Comment added) made by liturgist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Encodings iso8859_1 and latin_1 are redundant Initial Comment: ./lib/encodings contains both: iso8859_1.py latin_1.py Only one should be present. Martin says that latin_1 is faster. Using the 'iso' name would correlate better with the other ISO encodings provided. If the latin_1 code is faster, then it should be in the iso8859_1.py file. If an automated process produces the 'iso*' encodings, then it should either produce the faster code or stop producing iso8859_1. Regardless, one of the files should be removed. ---------------------------------------------------------------------- >Comment By: liturgist (liturgist) Date: 2005-08-12 09:01 Message: Logged In: YES user_id=197677 Where could one see some of the "shortcuts" in the Unicode integration code that make using "latin_1" faster in the runtime? I greped *.py and *.c, but could not readily identify any candidates. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-12 08:12 Message: Logged In: YES user_id=197677 Ok. How about if we specify iso8859_1 as "(see latin_1)" in the documentation? The code will work the same regardless of which encoding name the developer uses. Right? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-12 07:49 Message: Logged In: YES user_id=38388 Good point. The iso8859_1.py codec should be removed and added as alias to latin-1. Martin is right: the latin-1 codec is not only faster, but the Unicode integration code also has a lot of short-cuts for the "latin-1" encoding, so overall performance is better if you use that name for the encoding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&group_id=5470 From noreply at sourceforge.net Fri Aug 12 16:30:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 07:30:25 -0700 Subject: [ python-Bugs-1257525 ] Encodings iso8859_1 and latin_1 are redundant Message-ID: Bugs item #1257525, was opened at 2005-08-12 14:22 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Encodings iso8859_1 and latin_1 are redundant Initial Comment: ./lib/encodings contains both: iso8859_1.py latin_1.py Only one should be present. Martin says that latin_1 is faster. Using the 'iso' name would correlate better with the other ISO encodings provided. If the latin_1 code is faster, then it should be in the iso8859_1.py file. If an automated process produces the 'iso*' encodings, then it should either produce the faster code or stop producing iso8859_1. Regardless, one of the files should be removed. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-12 16:30 Message: Logged In: YES user_id=38388 To answer your questions: Yes, the encoding is the same for both latin-1 and iso8859-1. Specifying latin-1 instead of iso8859-1 will allow the code to use short-cuts. You have to grep for 'latin-1'. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-12 16:01 Message: Logged In: YES user_id=197677 Where could one see some of the "shortcuts" in the Unicode integration code that make using "latin_1" faster in the runtime? I greped *.py and *.c, but could not readily identify any candidates. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-08-12 15:12 Message: Logged In: YES user_id=197677 Ok. How about if we specify iso8859_1 as "(see latin_1)" in the documentation? The code will work the same regardless of which encoding name the developer uses. Right? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-12 14:49 Message: Logged In: YES user_id=38388 Good point. The iso8859_1.py codec should be removed and added as alias to latin-1. Martin is right: the latin-1 codec is not only faster, but the Unicode integration code also has a lot of short-cuts for the "latin-1" encoding, so overall performance is better if you use that name for the encoding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&group_id=5470 From noreply at sourceforge.net Fri Aug 12 17:00:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 08:00:09 -0700 Subject: [ python-Bugs-1257687 ] Solaris 8 declares gethostname(). Message-ID: Bugs item #1257687, was opened at 2005-08-12 11:00 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=1257687&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: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hans Deragon (deragon) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris 8 declares gethostname(). Initial Comment: In portpy.h line 377, we find: #ifdef SOLARIS /* Unchecked */ extern int gethostname(char *, int); #endif Well, on Solaris 8, that function is declared in /usr/include/unistd.h, thus a conflict. In unistd.h, there are a few #ifdef prior the declaration, so there might be some situation where the function is not declared. Of course, I cannot copy and paste the relevant section of unistd.h because of copyright. You might want to ask Sun Microsystem a copy of this file to patch this problem. My work around was to comment the above code in portpy.h. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257687&group_id=5470 From noreply at sourceforge.net Fri Aug 12 17:28:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 08:28:56 -0700 Subject: [ python-Bugs-1257728 ] error message incorrectly claims Visual C++ is required Message-ID: Bugs item #1257728, was opened at 2005-08-12 15:28 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=1257728&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: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: error message incorrectly claims Visual C++ is required Initial Comment: Thank you for the excellent distutils tool! Two problems: First, this error message is emitted on win32, but it appears to be incorrect, inasmuch as the Microsoft compiler is not actually required: """ error: Python was built with version 7.1 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed. Error: Subprocess exited with result 1 for project core """ Second, the usage of distutils is somewhat confusing, as the following line emits that error message: ./setup.py build -c mingw32; ./setup.py install but the following line, which I intuitively believed to be equivalent at first, works to compile and install the package: ./setup.py build -c mingw32 install ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257728&group_id=5470 From noreply at sourceforge.net Fri Aug 12 17:31:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 08:31:49 -0700 Subject: [ python-Bugs-1257731 ] Make set.remove() behave more like Set.remove() Message-ID: Bugs item #1257731, was opened at 2005-08-12 10:31 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=1257731&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: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Make set.remove() behave more like Set.remove() Initial Comment: class H(set): def __hash__(self):return id(self) s=H() f=set() f.add(s) f.remove(s) # this fails ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257731&group_id=5470 From noreply at sourceforge.net Fri Aug 12 17:43:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 08:43:35 -0700 Subject: [ python-Bugs-1257731 ] Make set.remove() behave more like Set.remove() Message-ID: Bugs item #1257731, was opened at 2005-08-12 10:31 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257731&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: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Make set.remove() behave more like Set.remove() Initial Comment: class H(set): def __hash__(self):return id(self) s=H() f=set() f.add(s) f.remove(s) # this fails ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257731&group_id=5470 From noreply at sourceforge.net Fri Aug 12 17:58:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 08:58:05 -0700 Subject: [ python-Bugs-1257772 ] tkapp read-only attributes Message-ID: Bugs item #1257772, was opened at 2005-08-12 17:57 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=1257772&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: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: peeb (peeble) Assigned to: Martin v. L?wis (loewis) Summary: tkapp read-only attributes Initial Comment: same as bug: [ 1164742 ] Tkdnd.py crashes due to read-only attributes Python 2.4.1 (#1, Mar 30 2005, 23:01:07) [GCC 3.3.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import Tkinter >>> r=Tkinter.Tk() >>> r.a=1 >>> del r.a Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/lib-tk/Tkinter.py", line 1660, in __delattr__ return delattr(self.tk, attr) TypeError: 'tkapp' object has only read-only attributes (del .a) The problem vanishes commenting out the __delattr__ methods in class Tk (module Tkinter.py): class Tk(Misc, Wm): ... def __delattr__(self, attr): "Delegate attribute access to the interpreter object" return delattr(self.tk, attr) I don't know if there is same subtle problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257772&group_id=5470 From noreply at sourceforge.net Fri Aug 12 20:04:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 11:04:34 -0700 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 13:42 Message generated for change (Settings changed) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&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: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) >Assigned to: Raymond Hettinger (rhettinger) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-10-05 18:59 Message: Logged In: YES user_id=139309 I would definitely have an immediate use for 3 byte integers.. the Mach- O executable format has a couple fields that are 3 byte unsigned integers (bit flags). py2app's supporting library macholib reads and writes this format directly. Currently I have several places that look like this: class dylib_reference(Structure): _fields_ = ( # XXX - ick, fix ('isym_flags', p_ulong), #('isym', p_ubyte * 3), #('flags', p_ubyte), ) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-02 16:00 Message: Logged In: YES user_id=80475 If no one other that the OP supports this, I would like to reject putting this in the struct module. Initially, it seemed like a fit because the endian options and whatnot are already in place; however, in one way or another each of the posters except the OP has stated good reasons for it not being in the struct module. Variable length C structure members are not what the module is about. Having to know the length in advance of the call is a killer. The learning curve issues with struct are also a problem. And, the use cases jsut don't point to struct. Put in a simple function in binascii or let's drop it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-10-02 15:34 Message: Logged In: YES user_id=341410 I have just attached a unified diff against structmodule.c 2.62 in CVS. It implements the semantics I have been describing, compiles cleanly, and produces proper results. >>> pickle.encode_long(83726) '\x0eG\x01' >>> struct.pack('<3g', 83726) '\x0eG\x01' >>> struct.unpack('<3g', struct.pack('<3g', 83726)) (83726L,) If the functionality is accepted, I will submit diffs for test_struct.py and libstruct.tex . ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-16 11:11 Message: Logged In: YES user_id=341410 Curse you Tim, for your core Python experience *wink*. Pickle is one example where a pascal-like encoding of longs was an encoding decision made to be flexible and space efficient. Certainly we have disparate use cases. Mine is for fixed struct-like records with multiple types. With pickle, any /thought/ of fixed records are tossed out the window with variable-lengthed types like strings, longs, lists, tuples and dicts, and I believe aren't really comparable. Now, variable-lengthed longs packed in little-endian format already have a mechanism for encoding and decoding via pickle.en/decode_long (though it is wholly undocumented), and seemingly is going to get another in binascii. Fixed-lengthed, optional signed/unsigned, optional little-endian/big-endian longs do not have a mechanism for encoding and decoding, which is what I am asking for. I will point out that 128 bit integers are gaining support on newer 32 and 64 bit processors and C compilers for them (SSE on x86, Itanium, etc.). In the future, a new code for these 128 bit integers may be asked for inclusion. With a variable-width integer type, all future "hey, we now have x-byte types in C, where is struct support in Python?", can be answered with the proposed, "choose your integer size" format code. That is to say, this format code is future proof, unless integer types start wandering from integer byte widths. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-15 19:52 Message: Logged In: YES user_id=31435 Use cases are important. Oddly(?) enough, I've never had a need for a bigint conversion in a C struct, and have a hard time imagining I will someday. All the cases I've had (and I've had more than a few) were one-shot str->long or long->str conversions. An obvious example in the core is the tedious encode_long() and decode_long() functions in pickle.py. Note that a pickle.encode_long() workalike doesn't know in advance how many bytes it needs, which would make using struct a PITA for that particular use case. If a proposal isn't convenient for taking over existing conversions of this nature, that counts against it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 19:31 Message: Logged In: YES user_id=341410 And as I stated, the 's' format character is also a "variable lengthed type". It just so happens that in most use cases I've had and observed for both the 's' format AND proposed 'g' format, the type size, is in fact, fixed at 'compile' time. It also happens that for the 'g' format, this fixed size is not in the set {1,2,4,8}, which are not limitations for the pre-existing 's' format. Please note that the only fundamental difference between the pre-existing 's' format and the proposed 'g' format, is that of a quick call to appropriate PyLong_* functions, and a range check as required by other integer types. Python is a tool. Struct is a tool. By changing the tool only slightly, we can add flexibility. The code is already there, minor glue would make it work, and would make it convenient for, I believe, more people than binascii. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-15 17:26 Message: Logged In: YES user_id=80475 I agree with Michael and Martin that variable length types do not belong in struct. The module is about working with fixed record layouts. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 17:17 Message: Logged In: YES user_id=341410 Raymond, from your first post on this topic, it seems as though you were previously implementing this functionality in binascii for some particular reason, and it seems as though it is to be included with binascii in the future, regardless of the outcome of this particular feature request. The only reason the binascii solution is better than status quo, is because a user doesn't need to implement arbitrarily large integer packing and unpacking themselves. On the other hand, it still requires the user make manual binascii.str_to_long(str_obj) calls in the case of it being part of a struct, so doesn't gain significantly. Now, one of the reasons why I requested a format code addition was because one can (un)pack multiple data types simultaneously with a single function call via struct. In nearly all of the use cases I have for packing and unpacking large integers, they are a part of other structures. In the cases where I have been packing and unpacking single integers, floats, etc., I still use struct because it is has nearly all of the functionality I need (signed, unsigned, big endian, little endian, char, short, long, long long, etc., lacking only arbitrarily large integer packing and unpacking). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-15 15:08 Message: Logged In: YES user_id=80475 My vote is for binascii functions to parallel hexlify and unhexlify. Ideally, it would give the same result as long(hexlify(s), 16). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 11:53 Message: Logged In: YES user_id=341410 As you state, it already supports packing and unpacking a variable-lengthed type: strings. In the use cases I've had and seen for (un)packing strings with struct, it is the most common to define a static format code, and use that all the time. That is, you see things like ">HLLHB25s", that become string constants in a module. On the _very rare_ occasion where people want more flexibility in their types, I have seen both the use of fixed and variable pascal strings... def packit(arg1, arg2, arg3, strng): return struct.pack(">LHH%ip"%len(strng), arg1, arg2, arg3, strng) I would not expect any pascal-string-like packing of a large integer, though it is possible. I do expect that most people have similar use cases as I, and would pre-define their struct formatting code. In the case of other similar requests (long to string, string to long via a base256 representation, etc.) for use in cryptography, I expect that the regularity of structures used in cryptography would almost certainly result in formatting codes being module constants. To sum up, both in the case for the 's' and 'p' format codes, and the proposed 'g'/'G' formatting codes, the vast majority of use cases pre-define the length of the string and large integer on a per-structure basis via "25s", "25p", or "25g". Rarely are the lengths truely variable in the case of "%ip"%len(strng). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 10:03 Message: Logged In: YES user_id=6656 Oops, I see you actually address that (ish). But I still feel packing what is an essentially variable length type using the struct module is a bit strange. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 10:02 Message: Logged In: YES user_id=6656 Josiah, what do you suggest struct.calcsize does with the format code your proposing? I think this question encapsulates why I find this feature request a bit misdirected. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-12 11:55 Message: Logged In: YES user_id=341410 Hexlify and unhexlify make sense for translating strings. Nowhere in the binascii module is there any mention of translating anything to/from integers, longs or floats. The only reason (un)hexlify make any sense at all is because we can get integers from hexlified strings, and get strings from hexlified integers with relative ease. I guess the trick with struct, at least with me, is not that I use it because it translates to/from C types, it is because it translates to/from types that I find useful. Its intersection with C types, as well as Python's intersection with C types, and my use intersection with the types is a convenient (but very engineered and understandable) coincidence. It would be another very convenient (but also engineered *wink*) coincidence if I didn't have to first extract a section of data, then translate it, in order to get one large integer. In the cases that I would truely find useful, big integers are a part of what would be called structs in the C world, and wouldn't require additional processing over what I'm already doing for other integers and floats. I was looking around, and it turns out that in 2001, Paul Rubin requested that one be able to translate to/from arbitrary bases via the C-level format function. In that discussion, Paul made the case that there should be a method to get arbitrarily long integers to and from strings: "The struct module doesn't give any way of converting arbitrary ints (meaning longs) to binary. Really, it's needed. Some people do it with gmpy, but if Python is going to support longs as a built-in type, one shouldn't have to resort to 3rd-party modules to read and write them in binary." Guido followed up with: "OK, I believe you. Can you submit a patch?" It seems like this was in reference to being able to use functions in binascii for converting to/from arbitrary packed binary integer types in base 256 (http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465045&group_id=5470 if you are interested). That request seems to have died because Paul dropped the ball. Me, I would prefer struct to binascii, if only because the code for doing this is already waiting to be used in struct, and because you can pull multiple objects from a single packed binary string, rather than one object per call. This would seemingly also satisfy complaints of being able to translate to/from base 256 for arbitrarily large integers. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-11 20:40 Message: Logged In: YES user_id=31435 binascii makes sense because that's where the hexlify and unhexlify functions live, which are small conceptual steps away from what's needed here. Methods on numbers make sense too, and only seem strange because so few are clearly visible now (although, e.g., there are lots of them already, like number.__abs__ and number.__add__). The struct module makes sense too, although it would be darned ugly to document a refusal to accept the new codes in "native" mode; and struct has a high learning curve; and struct obviously never intended to support types that aren't supplied directly by C compilers (the "Pascal string" code seems weird now, but not at the time). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-10 16:18 Message: Logged In: YES user_id=341410 (sorry it took me a few days to get back to you, I am on a contract deadline crunch...just taking a break now) The *HTTPServer heirarchy is interesting in its own right, but really, each piece in the heirarchy adds functionality. A similar thing can be said of asyncore and all the modules that derive from it (asynchat, *HTTPServer, *XMLRPCServer, smtpd, etc.). In this case, since the struct module is already in C and the functions are not subclassable, creating another module that parses strings and sends pieces off to struct for actual decoding seems like a waste of a module, especially when the change is so minor. Now, binascii is being used in such a fashion by uu and binhex, but that is because binascii is the data processing component, where uu and binhex make a 'pretty' interface. Struct doesn't need a pretty interface, it is already pretty. Though as I have said before, I think it could use this small addition. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 15:53 Message: Logged In: YES user_id=21627 Since you were asking: it is quite common that modules refer to related functionality. For example, BaseHTTPServer refers to SimpleHTTPServer and CGIHTTPServer. One might expect that a HTTP server also supports files and does CGI - but not this one; go elsewhere. Likewise, module binascii refers to modules uu and binhex. The math documentation points out that it does not support complex numbers, and that cmath is needed. The audioop documentation gives the function echocancel in the documentation, instead of implementing it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 15:38 Message: Logged In: YES user_id=341410 Martin, I was typing as you submitted your most recent comment. I am honestly shocked that you would suggest that longs should gain a method for encoding themselves as binary strings. Such a thing would then suggest that standard ints and floats also gain such methods. It would also imply that since one can go to strings, one should equivalently be able to come from strings via equivalent methods. Goodness, int.tostring(width) and int.fromstring(str)? But what about endianness? Looks like a big can of worms to me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 15:03 Message: Logged In: YES user_id=341410 Structures (aka C Structs) can contain arbitrarily large or small numbers of basic types inside them. As such, 'single long values' are still a valid use. I use struct for packing and unpacking of single items (8,4,2 byte integers, 1 byte integers are faster served via chr and ord) when necessary (because it is the most convenient), as well as a current contract where it is not uncommon to be packing and unpacking 256 byte structs. Those large structs contains various 1,2,4 and 8 byte integers, as well as a handful of 16 and 20 byte integers (which I must manually shift and mask during packing and unpacking). I'm a big boy, and can do it, but that doesn't mean that such functionality should be left out of Python. As for 'document the approach of going through hex inside the documentation of the struct module', I am curious about whether other modules do the same thing, that is to tell users "this functionality conceptually fits here X%, which is why it is documented here, but because it does not fit 100%, here is how you can do the same thing, which will likely look like a strange hack, require slicing potentially large strings, and be significantly slower than if we had just added the functionality, but here you go anyways." Now, I don't /need/ the feature, but I believe myself and others would find it useful. I also don't /require/ it be in struct, but no other modules offer equivalent functionality; Pickle and Marshal are Python-only, binascii (and bin2hex) are for converting between binary and ascii representations for transferring over non-8-bit channels (email, web, etc.), and no other module even comes close to offering a similar bit of "packs various types into a binary format, the same way C would" as struct. If anyone has a better place for it, I'm all ears (or eyes). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 14:45 Message: Logged In: YES user_id=21627 I would think that def long_as_bytes(lvalue, width): fmt = '%%.%dx' % (2*width) return unhexlify(fmt % (lvalue & ((1L<<8*width)-1))) is short enough for a recipe to not really make a C function necessary for that feature. However, if they are going to be provided somewhere, I would suggest that static methods on the long type might be the right place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 12:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 12:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 17:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-06 16:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 15:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Fri Aug 12 21:20:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 12:20:46 -0700 Subject: [ python-Bugs-1257960 ] gen_send_ex: Assertion `f->f_back != ((void *)0)' failed. Message-ID: Bugs item #1257960, was opened at 2005-08-12 19:20 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=1257960&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: None Status: Open Resolution: None Priority: 8 Submitted By: Neil Schemenauer (nascheme) Assigned to: Nobody/Anonymous (nobody) Summary: gen_send_ex: Assertion `f->f_back != ((void *)0)' failed. Initial Comment: Triggering is trival. Create a script that contains: def f(): yield 1 g = f() Run with a debug version of Python: python: ../Objects/genobject.c:85: gen_send_ex: Assertion `f->f_back != ((void *)0)' failed. Aborted (core dumped) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257960&group_id=5470 From noreply at sourceforge.net Fri Aug 12 22:56:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 13:56:52 -0700 Subject: [ python-Bugs-1252149 ] IOError after normal write Message-ID: Bugs item #1252149, was opened at 2005-08-04 19:30 Message generated for change (Comment added) made by patrick_gerken You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252149&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: Python 2.4 >Status: Deleted >Resolution: Invalid Priority: 5 Submitted By: Patrick Gerken (patrick_gerken) Assigned to: Nobody/Anonymous (nobody) Summary: IOError after normal write Initial Comment: After some Bughunting of Code with ConfigParser stuff which worked under Linux and didn't under Windows, it all boiled down to these three lines of codes: fp = open('bla','w+' fp.readline() fp.write('bla') Traceback (most recent call last): File "", line 1, in ? fp.write('bla') IOError: (0, 'Error') The same test under linux is a success. These teste have been run on the newest XP with python 2.4.1. ---------------------------------------------------------------------- >Comment By: Patrick Gerken (patrick_gerken) Date: 2005-08-12 20:56 Message: Logged In: YES user_id=1324112 I could not believe it and was searching for verification for this for a long time. If somebody does not believe it like I did: The C faq from usenet(Which I should have checked first...) answers this question too, and delivers two references: References: ANSI Sec. 4.9.5.3 ISO Sec. 7.9.5.3 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-08-04 19:51 Message: Logged In: YES user_id=31435 Well, this is pilot error, inherited from the limitations of C I/O: the effect of mixing reads with writes on a file open for update is entirely undefined unless a file-positioning operation occurs between them (for example, a seek()). I can't guess what you expect to happen, but seems most likely that what you intend could be obtained reliably by inserting fp.seek(fp.tell()) between your readline() and your write(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252149&group_id=5470 From noreply at sourceforge.net Fri Aug 12 23:22:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 14:22:12 -0700 Subject: [ python-Bugs-1252149 ] IOError after normal write Message-ID: Bugs item #1252149, was opened at 2005-08-04 15:30 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252149&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: Not a Bug >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Patrick Gerken (patrick_gerken) Assigned to: Nobody/Anonymous (nobody) Summary: IOError after normal write Initial Comment: After some Bughunting of Code with ConfigParser stuff which worked under Linux and didn't under Windows, it all boiled down to these three lines of codes: fp = open('bla','w+' fp.readline() fp.write('bla') Traceback (most recent call last): File "", line 1, in ? fp.write('bla') IOError: (0, 'Error') The same test under linux is a success. These teste have been run on the newest XP with python 2.4.1. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-08-12 17:22 Message: Logged In: YES user_id=31435 It's not _necessary_ to design an I/O library this way, and the Python docs aren't really clear about that Python's I/O inherits the quirks of the platform C's I/O, so don't at all feel bad about bringing it up. C libraries often exploit the latitude allowed by the C standards here to increase efficiency in "typical cases". ---------------------------------------------------------------------- Comment By: Patrick Gerken (patrick_gerken) Date: 2005-08-12 16:56 Message: Logged In: YES user_id=1324112 I could not believe it and was searching for verification for this for a long time. If somebody does not believe it like I did: The C faq from usenet(Which I should have checked first...) answers this question too, and delivers two references: References: ANSI Sec. 4.9.5.3 ISO Sec. 7.9.5.3 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-08-04 15:51 Message: Logged In: YES user_id=31435 Well, this is pilot error, inherited from the limitations of C I/O: the effect of mixing reads with writes on a file open for update is entirely undefined unless a file-positioning operation occurs between them (for example, a seek()). I can't guess what you expect to happen, but seems most likely that what you intend could be obtained reliably by inserting fp.seek(fp.tell()) between your readline() and your write(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252149&group_id=5470 From noreply at sourceforge.net Sat Aug 13 00:30:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 15:30:13 -0700 Subject: [ python-Bugs-1208304 ] urllib2's urlopen() method causes a memory leak Message-ID: Bugs item #1208304, was opened at 2005-05-25 09:20 Message generated for change (Comment added) made by jafo 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: Sean Reifschneider (jafo) Date: 2005-08-12 22:30 Message: Logged In: YES user_id=81797 I've just tried it again using the current CVS version as well as the version installed with Fedora Core 4, and in both cases I was able to run over 100,000 retrievals of http://127.0.0.1/test.html and http://127.0.0.1/google.html. test.html is just "it works" and google.html was generated with "wget -O google.html http://google.com/". I was able to reproduce this before, but now am not. My urllib2.py includes the r.recv=r.read line. I have upgraded from FC3 to FC4, could this be something related to an OS or library interaction? I was going to try to confirm the last message, but now I can't reproduce the failure. ---------------------------------------------------------------------- Comment By: Brian Wellington (bwelling) Date: 2005-08-12 02: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-29 03: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-29 03: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 23: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 From noreply at sourceforge.net Sat Aug 13 01:58:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 16:58:46 -0700 Subject: [ python-Bugs-1257731 ] Make set.remove() behave more like Set.remove() Message-ID: Bugs item #1257731, was opened at 2005-08-12 10:31 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257731&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: Fixed Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Make set.remove() behave more like Set.remove() Initial Comment: class H(set): def __hash__(self):return id(self) s=H() f=set() f.add(s) f.remove(s) # this fails ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-12 18:58 Message: Logged In: YES user_id=80475 Fixed. Lib/test/test_set.py 1.21 and 1.16.2.2 Objects/setobject.c 1.47 and 1.31.2.2, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257731&group_id=5470 From noreply at sourceforge.net Sat Aug 13 02:09:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 17:09:16 -0700 Subject: [ python-Bugs-1257960 ] gen_send_ex: Assertion `f->f_back != ((void *)0)' failed. Message-ID: Bugs item #1257960, was opened at 2005-08-12 14:20 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257960&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.5 Status: Open Resolution: None Priority: 8 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Phillip J. Eby (pje) Summary: gen_send_ex: Assertion `f->f_back != ((void *)0)' failed. Initial Comment: Triggering is trival. Create a script that contains: def f(): yield 1 g = f() Run with a debug version of Python: python: ../Objects/genobject.c:85: gen_send_ex: Assertion `f->f_back != ((void *)0)' failed. Aborted (core dumped) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-12 19:09 Message: Logged In: YES user_id=80475 I believe this is related to IDLE crash that I've been seeing. The problem did not occur just before the checkin: cvs up -D "2005-08-01 18:00" But emerged immediately after: cvs up -D "2005-08-01 21:00" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257960&group_id=5470 From noreply at sourceforge.net Sat Aug 13 05:29:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 12 Aug 2005 20:29:21 -0700 Subject: [ python-Bugs-1257960 ] gen_send_ex: Assertion `f->f_back != ((void *)0)' failed. Message-ID: Bugs item #1257960, was opened at 2005-08-12 19:20 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257960&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.5 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Neil Schemenauer (nascheme) Assigned to: Phillip J. Eby (pje) Summary: gen_send_ex: Assertion `f->f_back != ((void *)0)' failed. Initial Comment: Triggering is trival. Create a script that contains: def f(): yield 1 g = f() Run with a debug version of Python: python: ../Objects/genobject.c:85: gen_send_ex: Assertion `f->f_back != ((void *)0)' failed. Aborted (core dumped) ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2005-08-13 03:29 Message: Logged In: YES user_id=56214 Sadly, this is not the cause of the IDLE problem, because it's the assert that's wrong here. The problem that's occurring is that f->f_back is NULL because the final garbage collection at shutdown is occurring with a NULL tstate->frame. Changing the assert to check that f->f_back==tstate->frame makes the (meaningless) error go away. Basically, the problem here is because this code used to be the iternext routine, and it was never called by the GC. Now, generators are closed when they are garbage collected, so they can be executed during interpreter shutdown. I've checked in a corrected assertion. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-13 00:09 Message: Logged In: YES user_id=80475 I believe this is related to IDLE crash that I've been seeing. The problem did not occur just before the checkin: cvs up -D "2005-08-01 18:00" But emerged immediately after: cvs up -D "2005-08-01 21:00" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257960&group_id=5470 From noreply at sourceforge.net Sat Aug 13 15:34:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 13 Aug 2005 06:34:10 -0700 Subject: [ python-Bugs-1256669 ] Significant memory leak with PyImport_ReloadModule Message-ID: Bugs item #1256669, was opened at 2005-08-11 14:49 Message generated for change (Comment added) made by loewis 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. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-13 15:34 Message: Logged In: YES user_id=21627 How do you know there is a memory leak? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&group_id=5470 From noreply at sourceforge.net Sat Aug 13 16:05:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 13 Aug 2005 07:05:38 -0700 Subject: [ python-Bugs-1257687 ] Solaris 8 declares gethostname(). Message-ID: Bugs item #1257687, was opened at 2005-08-12 17:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257687&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: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hans Deragon (deragon) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris 8 declares gethostname(). Initial Comment: In portpy.h line 377, we find: #ifdef SOLARIS /* Unchecked */ extern int gethostname(char *, int); #endif Well, on Solaris 8, that function is declared in /usr/include/unistd.h, thus a conflict. In unistd.h, there are a few #ifdef prior the declaration, so there might be some situation where the function is not declared. Of course, I cannot copy and paste the relevant section of unistd.h because of copyright. You might want to ask Sun Microsystem a copy of this file to patch this problem. My work around was to comment the above code in portpy.h. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-13 16:05 Message: Logged In: YES user_id=21627 What precise problem does this cause? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257687&group_id=5470 From noreply at sourceforge.net Sat Aug 13 18:49:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 13 Aug 2005 09:49:31 -0700 Subject: [ python-Bugs-1258485 ] http auth documentation/implementation conflict Message-ID: Bugs item #1258485, was opened at 2005-08-13 18: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=1258485&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: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: http auth documentation/implementation conflict Initial Comment: [forwarded from http://bugs.debian.org/304925] Bug reporter writes: I was trying to implement a basic HTTP client using HTTP basic authorization. The current preferred method of doing this is by using urllib2 HTTPPasswordMgr. A simple test snippet to try this: pwmgr=urllib2.HTTPPasswordMgrWithDefaultRealm() pwmgr.add_password(None, url, username, password) handler=urllib2.HTTPBasicAuthHandler(pwmgr) opener=urllib2.build_opener(handler) urllib2.install_opener(opener) u=urllib2.urlopen(url) This did not work. Modifying the second line to: pwmgr.add_password(None, urlparse.urlparse(url)[1], username, password) fixed things, which shows a problem in the documentation: instead of a URI or sequence of URIs the add_password method takes a hostname. The documented behaviour would be better since it allows for multiple passwords per host, although in reality those will use different realms. So I suggest not changing the code in order to not break existing application but fixing the documentation instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258485&group_id=5470 From noreply at sourceforge.net Sat Aug 13 22:37:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 13 Aug 2005 13:37:08 -0700 Subject: [ python-Bugs-1124861 ] GetStdHandle in interactive GUI Message-ID: Bugs item #1124861, was opened at 2005-02-17 09:23 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124861&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: davids (davidschein) Assigned to: Nobody/Anonymous (nobody) Summary: GetStdHandle in interactive GUI Initial Comment: Using the suprocess module from with IDLE or PyWindows, it appears that calls GetStdHandle (STD__HANDLE) returns None, which causes an error. (All appears fine on Linux, the standard Python command-line, and ipython.) For example: >>> import subprocess >>> p = subprocess.Popen("dir", stdout=subprocess.PIPE) Traceback (most recent call last): File "", line 1, in -toplevel- p = subprocess.Popen("dir", stdout=subprocess.PIPE) File "C:\Python24\lib\subprocess.py", line 545, in __init__ (p2cread, p2cwrite, File "C:\Python24\lib\subprocess.py", line 605, in _get_handles p2cread = self._make_inheritable(p2cread) File "C:\Python24\lib\subprocess.py", line 646, in _make_inheritable DUPLICATE_SAME_ACCESS) TypeError: an integer is required The error originates in the mswindows implementation of _get_handles. You need to set one of stdin, stdout, or strerr because the first line in the method is: if stdin == None and stdout == None and stderr == None: ...return (None, None, None, None, None, None) I added "if not handle: return GetCurrentProcess()" to _make_inheritable() as below and it worked. Of course, I really do not know what is going on, so I am letting go now... def _make_inheritable(self, handle): ..."""Return a duplicate of handle, which is inheritable""" ...if not handle: return GetCurrentProcess() ...return DuplicateHandle(GetCurrentProcess(), handle, ....................................GetCurrentProcess(), 0, 1, ....................................DUPLICATE_SAME_ACCESS) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-08-13 14:37 Message: Logged In: YES user_id=945502 I ran into a similar problem in Ellogon (www.ellogon.org) which interfaces with Python through tclpython (http://jfontain.free.fr/tclpython.htm). My current workaround is to always set all of stdin, stdout, and stderr to subprocess.PIPE. I never use the stderr pipe, but at least this keeps the broken GetStdHandle calls from happening. Looking at the code, I kinda think the fix should be:: if handle is None: return handle return DuplicateHandle(GetCurrentProcess(), ... where if handle is None, it stays None. But I'm also probably in over my head here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124861&group_id=5470 From noreply at sourceforge.net Sun Aug 14 01:32:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 13 Aug 2005 16:32:26 -0700 Subject: [ python-Bugs-1100368 ] Wrong "type()" syntax in docs Message-ID: Bugs item #1100368, was opened at 2005-01-11 12:03 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100368&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: Facundo Batista (facundobatista) Assigned to: Raymond Hettinger (rhettinger) Summary: Wrong "type()" syntax in docs Initial Comment: >From the current docs: type(object): Return the type of an object. The return value is a type object. >From the interpreter: >>> help(type) Help on class type in module __builtin__: class type(object) | type(object) -> the object's type | type(name, bases, dict) -> a new type In the documentation is missing the second syntax form. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-08-13 17:32 Message: Logged In: YES user_id=945502 I was going to file this as a new bug report, but I changed my mind and decided to post it as a followup to this bug instead. It's basically a first draft at some documentation for the behavior of the type type. ---------- The type object documentation is limited and hard to find. The call type(obj) is defined in http://docs.python.org/lib/built-in-funcs.html and the call type(name, bases, dict) is briefly mentioned in http://docs.python.org/ref/metaclasses.html. Confusingly, the section on Type Objects (http://www.python.org/dev/doc/devel/lib/bltin-type-objects.html) is not about the type object at all; it's about *instances* of type, e.g. int or str. I'd like to add a section on the type object itself, something like: """ type(name, bases, dict) Return a new type object. This is essentially a functional form of the class statement: the "name" string is the class name and becomes the __name__ attribute, the "bases" tuple is the class bases and becomes the __bases__ attribute, the "dict" dict is the namespace defined by the class body, and becomes the __dict__ attribute. For example, the following two statements create identical "type" objects: >>> class X(object): ... a = 1 ... >>> X = type('X', (object,), dict(a=1)) Just like type objects created by class statements, type objects created by type() are callable, and when called create new instances of their type. The __call__() method of type objects accepts any number of positional and keyword arguments, and passes these to the type object's __new__() method to create a new instance. If __new__() returns an instance of the same type, that instance's __init__() method is then called with the same arguments. In either case, the __call__() method then returns the new instance. """ I don't know where this should go, but I'd certainly like to see something like this put in, and linked under the type() function, the Type Objects section and the Customizing class creation (metaclasses) section. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-01-25 14:31 Message: Logged In: YES user_id=99874 cjwhrh's comment doesn't seem relevent. It is generally true of ALL builtins that they can be shadowed by local variables. Facundo is probably right that the newer use of type() should be documented. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-01-18 15:03 Message: Logged In: YES user_id=285587 The accuracy of the above depends partly on the context. Within a function or method which has "type" as a parameter the type function described above is no longer accessible. Colin W. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100368&group_id=5470 From noreply at sourceforge.net Sun Aug 14 12:35:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 14 Aug 2005 03:35:18 -0700 Subject: [ python-Bugs-1257687 ] Solaris 8 declares gethostname(). Message-ID: Bugs item #1257687, was opened at 2005-08-12 11:00 Message generated for change (Comment added) made by deragon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257687&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: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hans Deragon (deragon) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris 8 declares gethostname(). Initial Comment: In portpy.h line 377, we find: #ifdef SOLARIS /* Unchecked */ extern int gethostname(char *, int); #endif Well, on Solaris 8, that function is declared in /usr/include/unistd.h, thus a conflict. In unistd.h, there are a few #ifdef prior the declaration, so there might be some situation where the function is not declared. Of course, I cannot copy and paste the relevant section of unistd.h because of copyright. You might want to ask Sun Microsystem a copy of this file to patch this problem. My work around was to comment the above code in portpy.h. ---------------------------------------------------------------------- >Comment By: Hans Deragon (deragon) Date: 2005-08-14 06:35 Message: Logged In: YES user_id=148726 When compiling beecrypt, it complained that gethostname() was declared twice. Seams that beecrypt was compiling something for python and thus included pyport.h. At the same time, it was including unistd.h. That cause beecrypt compilation to halt with an error. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-13 10:05 Message: Logged In: YES user_id=21627 What precise problem does this cause? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257687&group_id=5470 From noreply at sourceforge.net Sun Aug 14 13:00:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 14 Aug 2005 04:00:51 -0700 Subject: [ python-Bugs-1258922 ] "it's" vs. "its" typo in Language Reference Message-ID: Bugs item #1258922, was opened at 2005-08-14 13:00 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=1258922&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: Wolfgang Petzold (wolpertinger) Assigned to: Nobody/Anonymous (nobody) Summary: "it's" vs. "its" typo in Language Reference Initial Comment: Python 2.4.1 OS: All In section 2.3.2 "Reserved classes of identifiers", second item "__*__", the term "by the interpreter and it's implementation" should by changed to "by the interpreter and its implementation". We are talking about the implementation of the interpreter, and "it's"="it is" is not appropriate here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258922&group_id=5470 From noreply at sourceforge.net Sun Aug 14 13:19:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 14 Aug 2005 04:19:37 -0700 Subject: [ python-Bugs-1258922 ] "it's" vs. "its" typo in Language Reference Message-ID: Bugs item #1258922, was opened at 2005-08-14 13:00 Message generated for change (Comment added) made by wolpertinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258922&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: Wolfgang Petzold (wolpertinger) Assigned to: Nobody/Anonymous (nobody) Summary: "it's" vs. "its" typo in Language Reference Initial Comment: Python 2.4.1 OS: All In section 2.3.2 "Reserved classes of identifiers", second item "__*__", the term "by the interpreter and it's implementation" should by changed to "by the interpreter and its implementation". We are talking about the implementation of the interpreter, and "it's"="it is" is not appropriate here. ---------------------------------------------------------------------- >Comment By: Wolfgang Petzold (wolpertinger) Date: 2005-08-14 13:19 Message: Logged In: YES user_id=1272126 I've just browsed through the CVS web interface and found the typo already fixed in revision 1.58 of ref2.tex (on the MAIN branch). That should change the status of this bug report, but I am not sure what to. "Pending/Fixed"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258922&group_id=5470 From noreply at sourceforge.net Sun Aug 14 14:38:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 14 Aug 2005 05:38:15 -0700 Subject: [ python-Bugs-1258922 ] "it's" vs. "its" typo in Language Reference Message-ID: Bugs item #1258922, was opened at 2005-08-14 13:00 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258922&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: Closed >Resolution: Out of Date Priority: 5 Submitted By: Wolfgang Petzold (wolpertinger) Assigned to: Nobody/Anonymous (nobody) Summary: "it's" vs. "its" typo in Language Reference Initial Comment: Python 2.4.1 OS: All In section 2.3.2 "Reserved classes of identifiers", second item "__*__", the term "by the interpreter and it's implementation" should by changed to "by the interpreter and its implementation". We are talking about the implementation of the interpreter, and "it's"="it is" is not appropriate here. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-14 14:38 Message: Logged In: YES user_id=1188172 It'll be "Out of Date", then. ;-) ---------------------------------------------------------------------- Comment By: Wolfgang Petzold (wolpertinger) Date: 2005-08-14 13:19 Message: Logged In: YES user_id=1272126 I've just browsed through the CVS web interface and found the typo already fixed in revision 1.58 of ref2.tex (on the MAIN branch). That should change the status of this bug report, but I am not sure what to. "Pending/Fixed"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258922&group_id=5470 From noreply at sourceforge.net Sun Aug 14 15:11:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 14 Aug 2005 06:11:40 -0700 Subject: [ python-Bugs-1258986 ] Makefile ignores $CPPFLAGS Message-ID: Bugs item #1258986, was opened at 2005-08-14 15:11 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=1258986&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: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dirk Pirschel (pirschel) Assigned to: Nobody/Anonymous (nobody) Summary: Makefile ignores $CPPFLAGS Initial Comment: Makefile ignores $CPPFLAGS Environment variable. Solution: patch Makefile.pre.in with ----- snip ----- 59c59 < CPPFLAGS= -I. -I$(srcdir)/Include --- > CPPFLAGS= -I. -I$(srcdir)/Include @CPPFLAGS@ ----- snip ----- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258986&group_id=5470 From noreply at sourceforge.net Sun Aug 14 21:07:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 14 Aug 2005 12:07:11 -0700 Subject: [ python-Bugs-1256786 ] slice object uses -1 as exclusive end-bound Message-ID: Bugs item #1256786, was opened at 2005-08-11 16:08 Message generated for change (Comment added) made by mwh 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: Michael Hudson (mwh) 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. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-08-14 20:07 Message: Logged In: YES user_id=6656 Did you see my follow up on clpy? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-08-12 14:02 Message: Logged In: YES user_id=6656 This is clearly in my area. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256786&group_id=5470 From noreply at sourceforge.net Mon Aug 15 03:09:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 14 Aug 2005 18:09:08 -0700 Subject: [ python-Bugs-1259434 ] Tix CheckList 'radio' option cannot be changed Message-ID: Bugs item #1259434, was opened at 2005-08-14 20:09 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=1259434&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: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Maple (ray_maple) Assigned to: Martin v. L?wis (loewis) Summary: Tix CheckList 'radio' option cannot be changed Initial Comment: The 'radio' option to the Tix.CheckList widget cannot be set. Attempting to change the option during widget creation results in the following error: _tkinter.TclError: cannot assigned to static variable "-radio" The radio option is declared static in the Tix tcl library, and must be set at widget creation time. The radio option is not included in the list of static options passed to TixWidget.__init__ from CheckList.__init__ in file Tix.py. Solution: Add 'radio' to the list of static options passed to TixWidget.__init__ in Tix.py. Output from diff -C 1: *** 1562,1564 **** TixWidget.__init__(self, master, 'tixCheckList', ! ['options'], cnf, kw) self.subwidget_list['hlist'] = _dummyHList(self, 'hlist') --- 1562,1564 ---- TixWidget.__init__(self, master, 'tixCheckList', ! ['options','radio'], cnf, kw) self.subwidget_list['hlist'] = _dummyHList(self, 'hlist') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1259434&group_id=5470 From noreply at sourceforge.net Mon Aug 15 13:39:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 15 Aug 2005 04:39:17 -0700 Subject: [ python-Bugs-1257255 ] tarfile local name is local, should be abspath Message-ID: Bugs item #1257255, was opened at 2005-08-12 04:26 Message generated for change (Comment added) made by gustaebel 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. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-08-15 13:39 Message: Logged In: YES user_id=642936 Could you please attach the test code you mentioned? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257255&group_id=5470 From noreply at sourceforge.net Mon Aug 15 19:34:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 15 Aug 2005 10:34:22 -0700 Subject: [ python-Bugs-1257255 ] tarfile local name is local, should be abspath Message-ID: Bugs item #1257255, was opened at 2005-08-12 02:26 Message generated for change (Comment added) made by blais 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. ---------------------------------------------------------------------- >Comment By: Martin Blais (blais) Date: 2005-08-15 17:34 Message: Logged In: YES user_id=10996 Oops, that was silly. My apologies. Here goes the file... ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-08-15 11:39 Message: Logged In: YES user_id=642936 Could you please attach the test code you mentioned? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257255&group_id=5470 From noreply at sourceforge.net Mon Aug 15 20:13:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 15 Aug 2005 11:13:28 -0700 Subject: [ python-Bugs-1208304 ] urllib2's urlopen() method causes a memory leak Message-ID: 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-15 11:13 Message: Logged In: YES user_id=63197 The real problem we were seeing wasn't the memory leak, it was a file descriptor leak. Leaking references within the interpreter is bad, but the garbage collector will eventually notice that the system is out of memory and clean them. Leaking file descriptors is much worse, as gc won't be triggered when the process has reached it's limit, and the process will start failing with "Too many file descriptors". To easily show this problem, run the following from an interactive python interpreter: import urllib2 f = urllib2.urlopen('http://www.google.com') f.close() and from another window, run "lsof -p ". It should show a TCP socket in CLOSE_WAIT, which means the file descriptor is still open. I'm seeing weirdness on Fedora Core 4 today that I didn't see last week where after a few seconds, the file descriptor is listed as "can't identify protocol" instead of TCP, but that's not too relevant, since it's still open. Repeating the urllib2.urlopen()/close() pairs of statements in the interpreter will cause more fds to be leaked, which can also be seen by lsof. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-08-12 15:30 Message: Logged In: YES user_id=81797 I've just tried it again using the current CVS version as well as the version installed with Fedora Core 4, and in both cases I was able to run over 100,000 retrievals of http://127.0.0.1/test.html and http://127.0.0.1/google.html. test.html is just "it works" and google.html was generated with "wget -O google.html http://google.com/". I was able to reproduce this before, but now am not. My urllib2.py includes the r.recv=r.read line. I have upgraded from FC3 to FC4, could this be something related to an OS or library interaction? I was going to try to confirm the last message, but now I can't reproduce the failure. ---------------------------------------------------------------------- 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 From noreply at sourceforge.net Mon Aug 15 20:14:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 15 Aug 2005 11:14:20 -0700 Subject: [ python-Bugs-900092 ] hotshot.stats.load Message-ID: Bugs item #900092, was opened at 2004-02-19 03:05 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&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: Fixed Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Brett Cannon (bcannon) Summary: hotshot.stats.load Initial Comment: trying to do a hotshot.stats.load("myprofiling_file.prof") fails with assertionerror assert not self._stack python 2.3.2 on WinXP ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-08-15 14:14 Message: Logged In: YES user_id=12800 Patches applied for Python 2.4.2 and 2.5a1 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-07-08 11:02 Message: Logged In: YES user_id=12800 900092-patch-2.txt fixes the test suite for the extra return event. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-07-07 19:26 Message: Logged In: YES user_id=12800 See 900092-patch.txt for a candidate patch against Python 2.4.1. Props to Justin Campbell for most of the heavily lifting (but you can blame me for any problems ;). This fix restore the tracing of a 'return' event for exceptions that cause a function to exit. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-11-08 18:54 Message: Logged In: YES user_id=86307 Well, the superficial fix doesn't work (sorry for posting too soon). It turns out that PyTrace_EXCEPTION is sent for any exception, not just one causing the function to exit. So I guess the best fix may be to have hotshot always install its profiler_callback to handle CALLS and RETURNS, and then optionally install the tracer_callback to handle only LINEs. Anyway, that works for the one test case I've been using (a runcall of a function which simply does "import pickle"). By the way, I'm testing with 2.4b1. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-11-08 18:32 Message: Logged In: YES user_id=86307 I ran into this today, so I decided to look into it. It looks to me like the problem only happens if you profile with lineevents enabled. In that case, hotshot uses the tracer_callback function (in _hotshot.c) to dispatch trace events. This function explicitly ignores exception returns (PyTrace_EXCEPTION), which can lead to an unbalanced stack of calls/returns when the log is loaded (if an profiled function exits with an exception). It seems on the surface that tracer_callback ought to handle exceptions the same way as normal returns. This would be consistent with what happens when profiler_callback is used, since PyEval_EvalFrame dispatches sends a Py_RETURN to c_profilefunc when exiting because of an exception. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-27 10:41 Message: Logged In: YES user_id=12800 Could this be related to 1019882? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-24 18:00 Message: Logged In: YES user_id=469548 Hmm, the file was too big, even though it was compressed. I've uploaded it to http://home.student.uva.nl/johannes.gijsbers/roundup.prof.bz2 now. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-24 17:58 Message: Logged In: YES user_id=469548 While the original report isn't very useful, I've ran into this problem multiple times as well. I can reproduce it using the attached profile file (compressed because of the large size) and the following console session: Python 2.3.4 (#2, Jul 5 2004, 09:15:05) [GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import hotshot.stats >>> stats = hotshot.stats.load('roundup.prof') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/hotshot/stats.py", line 12, in load return StatsLoader(filename).load() File "/usr/lib/python2.3/hotshot/stats.py", line 51, in load assert not self._stack AssertionError >>> I'm not sure who's baby hotshot really is, so I'm leaving this unassigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470 From noreply at sourceforge.net Mon Aug 15 21:15:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 15 Aug 2005 12:15:12 -0700 Subject: [ python-Bugs-1260171 ] subprocess: more general (non-buffering) communication Message-ID: Bugs item #1260171, was opened at 2005-08-15 14:15 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=1260171&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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Ian Bicking (ianbicking) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess: more general (non-buffering) communication Initial Comment: Right now you can use subprocess.Popen.communicate() to make communication with subprocesses much easier and less likely to block than communicating directly with .stdin, .stdout, etc. However, that requires completely buffering the input and output. The functionality of communicate() (which is somewhat complex because of platform issues) could be made more general fairly easily. The current functionality of communicate could then be implemented in terms of that new method. I attached a function I'm using which does that for the posix systems (basically turning Popen's posix communicate into a function with some modifications). Replace "proc" with "self" (and give the function a better name) and you'd have a method. If patch 1175984 was accepted, then this wouldn't be that much of an issue: http://sourceforge.net/tracker/index.php?func=detail&aid=1175984&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1260171&group_id=5470 From noreply at sourceforge.net Tue Aug 16 15:56:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 16 Aug 2005 06:56:01 -0700 Subject: [ python-Bugs-1256669 ] Significant memory leak with PyImport_ReloadModule Message-ID: Bugs item #1256669, was opened at 2005-08-11 12:49 Message generated for change (Comment added) made by bheld 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. ---------------------------------------------------------------------- >Comment By: Ben Held (bheld) Date: 2005-08-16 13:56 Message: Logged In: YES user_id=1327580 Boundschecker shows the leak and I have verified this by watching the process memory increase via the task manager. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-13 13:34 Message: Logged In: YES user_id=21627 How do you know there is a memory leak? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&group_id=5470 From noreply at sourceforge.net Tue Aug 16 20:53:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 16 Aug 2005 11:53:23 -0700 Subject: [ python-Bugs-1261229 ] __new__ is class method Message-ID: Bugs item #1261229, was opened at 2005-08-16 18:53 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=1261229&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: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Orr (hierro) Assigned to: Nobody/Anonymous (nobody) Summary: __new__ is class method Initial Comment: Section 3.3.1 of the Language Reference says, " __new__() is a static method" But it's actually a class method since it's first argument is the class. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261229&group_id=5470 From noreply at sourceforge.net Tue Aug 16 23:46:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 16 Aug 2005 14:46:25 -0700 Subject: [ python-Bugs-1261390 ] import dynamic library bug? Message-ID: Bugs item #1261390, was opened at 2005-08-16 14:46 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=1261390&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: broadwin (broadwin) Assigned to: Nobody/Anonymous (nobody) Summary: import dynamic library bug? Initial Comment: I have just upgraded my tcl/tk to 8.4 on my linux system. Now I have two sets of tcl/tk, the old one (8.3) is installed under /usr, and the new one (8.4) is installed under /usr/local. I also upgraded to Python 2.4.1. Compiling Python went fine. It found the new tcl/tk correctly to build _tkinter.so. However it broke on trying to import, telling me that it could not find libtk84.so, even though it found it to build the _tkinter.so. Creating symbolic links under /usr/lib to libtk and libtcl solved the problem. It seems to me that import was confused and did not search /usr/local/lib. I use bash. Maybe I need to set some environmental variable? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261390&group_id=5470 From noreply at sourceforge.net Wed Aug 17 07:10:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 16 Aug 2005 22:10:58 -0700 Subject: [ python-Bugs-1261659 ] Tutorial doesn't cover * and ** function calls Message-ID: Bugs item #1261659, was opened at 2005-08-16 22:10 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=1261659&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: None Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial doesn't cover * and ** function calls Initial Comment: While the tutorial, in the section discussing function definitions, covers * and ** arguments, there is no aparent coverage of using them in a function call (e.g., ``open(*["file", "r"])``). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261659&group_id=5470 From noreply at sourceforge.net Wed Aug 17 08:50:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 16 Aug 2005 23:50:54 -0700 Subject: [ python-Bugs-1261714 ] precompiled code and nameError. Message-ID: Bugs item #1261714, was opened at 2005-08-17 13:50 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=1261714&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: None Status: Open Resolution: None Priority: 5 Submitted By: Vladimir Menshakov (megath) Assigned to: Nobody/Anonymous (nobody) Summary: precompiled code and nameError. Initial Comment: i experienced problem with call'ing python unmarshalled and eval'ed code. similar problem described in mailing list, but unfortunately has not got any solution or work-around. http://mail.python.org/pipermail/c++-sig/2003-October/006094.html actually I have code like this: ------------- import m class A: def do(self): print m.User().GetName() ------------ test.py a = A() a.do() running script from python works perfectly. but when I call 'do' from c++ code I get following error : PyObject_CallMethod: exceptions.NameError:global name 'm' is not defined I checked locals dictionary, it contains missing name ('m'). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261714&group_id=5470 From noreply at sourceforge.net Wed Aug 17 14:34:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 17 Aug 2005 05:34:24 -0700 Subject: [ python-Bugs-1257255 ] tarfile local name is local, should be abspath Message-ID: Bugs item #1257255, was opened at 2005-08-12 04:26 Message generated for change (Comment added) made by gustaebel 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. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-08-17 14:34 Message: Logged In: YES user_id=642936 Thank you very much for your report. I added patch #1262036 that ought to fix the problem. ---------------------------------------------------------------------- Comment By: Martin Blais (blais) Date: 2005-08-15 19:34 Message: Logged In: YES user_id=10996 Oops, that was silly. My apologies. Here goes the file... ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-08-15 13:39 Message: Logged In: YES user_id=642936 Could you please attach the test code you mentioned? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257255&group_id=5470 From noreply at sourceforge.net Wed Aug 17 19:11:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 17 Aug 2005 10:11:19 -0700 Subject: [ python-Bugs-1262320 ] minidom.py alternate newl support is broken Message-ID: Bugs item #1262320, was opened at 2005-08-17 10:11 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=1262320&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: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Whitley (jwhitley) Assigned to: Nobody/Anonymous (nobody) Summary: minidom.py alternate newl support is broken Initial Comment: In minidom.py, class Document and a few other nodes have hardcoded newlines ('\n') remaining, causing the "newl" parameter to potentially produce a file with mixed line endings, e.g. if newl is set to Windows line endings ("\r\n" ). A diff follows which fixes all instances of the problem of which I'm aware. *** /usr/lib/python2.4/xml/dom/minidom.py.orig Tue Aug 16 17:38:40 2005 --- /usr/lib/python2.4/xml/dom/minidom.py.new Tue Aug 16 17:38:40 2005 *************** *** 1286,1292 **** writer.write(" [") writer.write(self.internalSubset) writer.write("]") ! writer.write(">\n") class Entity(Identified, Node): attributes = None --- 1286,1292 ---- writer.write(" [") writer.write(self.internalSubset) writer.write("]") ! writer.write(">%s" % newl) class Entity(Identified, Node): attributes = None *************** *** 1739,1747 **** def writexml(self, writer, indent="", addindent="", newl="", encoding = None): if encoding is None: ! writer.write('\n') else: ! writer.write('\n' % encoding) for node in self.childNodes: node.writexml(writer, indent, addindent, newl) --- 1739,1747 ---- def writexml(self, writer, indent="", addindent="", newl="", encoding = None): if encoding is None: ! writer.write('%s' % newl) else: ! writer.write('%s' % (encoding,newl)) for node in self.childNodes: node.writexml(writer, indent, addindent, newl) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1262320&group_id=5470 From noreply at sourceforge.net Thu Aug 18 10:54:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 18 Aug 2005 01:54:09 -0700 Subject: [ python-Bugs-1262856 ] fcntl.ioctl have a bit problem. Message-ID: Bugs item #1262856, was opened at 2005-08-18 16:53 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=1262856&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: Raise L. Sail (fullsail) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl.ioctl have a bit problem. Initial Comment: First, I write python program on Linux. The function ioctl of fcntl module, take a integer parameter as ioctl command. in python 2.3.x, if this command value is more than 0x80000000, interpreter will popup some warnning message. but in python 2.4.x, it raise a exception directly. My solution is writing one cutoms module in C. but this is so ugly. There are some ioctl command value are more than 0x80000000, I think we should not reject "negative" ioctl command. enjoy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1262856&group_id=5470 From noreply at sourceforge.net Thu Aug 18 16:42:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 18 Aug 2005 07:42:39 -0700 Subject: [ python-Bugs-1263086 ] typo on "SimpleXMLRPCServer Objects" Message-ID: Bugs item #1263086, was opened at 2005-08-18 10:42 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=1263086&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: None Status: Open Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Nobody/Anonymous (nobody) Summary: typo on "SimpleXMLRPCServer Objects" Initial Comment: s/note tha params/note that params/ http://www.python.org/dev/doc/devel/lib/simple-xmlrpc-servers.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263086&group_id=5470 From noreply at sourceforge.net Thu Aug 18 21:49:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 18 Aug 2005 12:49:11 -0700 Subject: [ python-Bugs-1263086 ] typo on "SimpleXMLRPCServer Objects" Message-ID: Bugs item #1263086, was opened at 2005-08-18 16:42 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263086&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Nobody/Anonymous (nobody) Summary: typo on "SimpleXMLRPCServer Objects" Initial Comment: s/note tha params/note that params/ http://www.python.org/dev/doc/devel/lib/simple-xmlrpc-servers.html ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-08-18 21:49 Message: Logged In: YES user_id=89016 Checked in a fix as Doc/lib/libsimplexmlrpc.tex 1.10 and 1.7.2.2. Thanks for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263086&group_id=5470 From noreply at sourceforge.net Thu Aug 18 22:17:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 18 Aug 2005 13:17:28 -0700 Subject: [ python-Bugs-1251300 ] Decoding with unicode_internal segfaults on UCS-4 builds Message-ID: Bugs item #1251300, was opened at 2005-08-03 21:49 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&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: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nik Haldimann (nhaldimann) Assigned to: M.-A. Lemburg (lemburg) Summary: Decoding with unicode_internal segfaults on UCS-4 builds Initial Comment: On UCS-4 builds, decoding a byte string with the unicode_internal codec doesn't correctly work for code points from 0x80000000 upwards and even segfaults. I have observed the same behaviour on 2.5 from CVS and 2.4.0 on OS X/PowerPC as well as on 2.3.5 on Linux/x86. Here's an example: Python 2.5a0 (#1, Aug 3 2005, 21:34:05) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> "\x7f\xff\xff\xff".decode("unicode_internal") u'\U7fffffff' >>> "\x80\x00\x00\x00".decode("unicode_internal") u'\x00' >>> "\x80\x00\x00\x01".decode("unicode_internal") u'\x01' >>> "\x81\x00\x00\x00".decode("unicode_internal") Segmentation fault On little endian architectures the byte strings must be reversed for the same effect. I'm not sure if I understand what's going on, but I guess there are 2 solution strategies: 1. Make unicode_internal work for any code point up to 0xFFFFFFFF. 2. Make unicode_internal raise a UnicodeDecodeError for anything above 0x10FFFF (== sys.maxunicode for UCS-4 builds). It seems like there are no unicode code points above 0x10FFFF, so the latter solution feels more correct to me, even though it might break backwards compatibility a tiny bit. The unicodeescape codec already does a similar thing: >>> u"\U00110000" UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-08-18 22:17 Message: Logged In: YES user_id=89016 The patch has a problem with input strings of a length that is not a multiple of 4, e.g. "\x00".decode("unicode-internal") returns u"" instead of raising an error. Also in a UCS-2 build most of the tests are irrelevant (as it's not possible to create codepoints above 0x10ffff even when using surrogates), so probably they should be ifdef'd out. ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 23:08 Message: Logged In: YES user_id=1317086 Here's the patch with error handler support + test. Again: Please review carefully. ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 18:35 Message: Logged In: YES user_id=1317086 Ah, that PEP clears some things up for me. I will look into it, but I hope you realize this requires tinkering with unicodeobject.c since the error handler code seems to live there. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-05 18:03 Message: Logged In: YES user_id=89016 Your patch doesn't support PEP 293 error handlers. Could you add support for that? ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 16:50 Message: Logged In: YES user_id=1317086 OK, I put something together. Please review carefully as I'm not very familiar with the C API. I have tested this with the CVS HEAD on OS X and Linux. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:41 Message: Logged In: YES user_id=38388 I think solution 2 is the right approach, since UCS-4 only has 0x10FFFF possible code points. Could you provide a patch ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&group_id=5470 From noreply at sourceforge.net Fri Aug 19 04:07:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 18 Aug 2005 19:07:29 -0700 Subject: [ python-Bugs-1263635 ] type() and isinstance() do not call __getattribute__ Message-ID: Bugs item #1263635, was opened at 2005-08-19 04:07 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=1263635&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: Per Vognsen (pervognsen) Assigned to: Nobody/Anonymous (nobody) Summary: type() and isinstance() do not call __getattribute__ Initial Comment: The built-in functions type() and isinstance() do not call __getattribute__ for instances of user-defined classes. Thus, for instance, x.__class__ == sometype and type(x) == sometype can give inconsistent results. I ran into this problem in writing a transparent persistence system, where instances of proxy classes are used as stand-ins for unloaded objects and the proxy does just-in-time loading by overloading __getattribute__ and __setattr__ (which changes __class__). (This applies to 2.4.1.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263635&group_id=5470 From noreply at sourceforge.net Fri Aug 19 04:35:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 18 Aug 2005 19:35:17 -0700 Subject: [ python-Bugs-1263656 ] IDLE on Mac Message-ID: Bugs item #1263656, was opened at 2005-08-18 22:35 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=1263656&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: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE on Mac Initial Comment: Copying code from some browsers into IDLE on the Mac can leave the file with only \r (13) at the ends of lines (Safari doesn't seem to have this problem). Then checksyntax() in ScriptBinding.py fails to convert these into \n (10), and compile() fails. The effect is that a program which Python is willing to run gets a syntax error in IDLE. I think the fix is in checksyntax() to add after source = re.sub(r"\r\n", "\n", source) the following statement, which converts unaccompanied \r's into \n's:: source = re.sub(r"\r", "\n", source) I've tried this and it works, but someone with a better overview of end-of-line issues in Python should think through whether this is the appropriate fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263656&group_id=5470 From noreply at sourceforge.net Fri Aug 19 06:23:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 18 Aug 2005 21:23:01 -0700 Subject: [ python-Bugs-1263656 ] IDLE on Mac Message-ID: Bugs item #1263656, was opened at 2005-08-18 22:35 Message generated for change (Comment added) made by bsherwood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263656&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: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE on Mac Initial Comment: Copying code from some browsers into IDLE on the Mac can leave the file with only \r (13) at the ends of lines (Safari doesn't seem to have this problem). Then checksyntax() in ScriptBinding.py fails to convert these into \n (10), and compile() fails. The effect is that a program which Python is willing to run gets a syntax error in IDLE. I think the fix is in checksyntax() to add after source = re.sub(r"\r\n", "\n", source) the following statement, which converts unaccompanied \r's into \n's:: source = re.sub(r"\r", "\n", source) I've tried this and it works, but someone with a better overview of end-of-line issues in Python should think through whether this is the appropriate fix. ---------------------------------------------------------------------- >Comment By: Bruce Sherwood (bsherwood) Date: 2005-08-19 00:23 Message: Logged In: YES user_id=34881 A footnote: Now I don't understand why the substitution searches for r"\r\n", since this would seem to be the raw string which represents slash, r, slash, n, not the two-character string "\r\n"....?? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263656&group_id=5470 From noreply at sourceforge.net Fri Aug 19 16:17:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 19 Aug 2005 07:17:47 -0700 Subject: [ python-Bugs-1251300 ] Decoding with unicode_internal segfaults on UCS-4 builds Message-ID: Bugs item #1251300, was opened at 2005-08-03 21:49 Message generated for change (Comment added) made by nhaldimann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&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: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nik Haldimann (nhaldimann) Assigned to: M.-A. Lemburg (lemburg) Summary: Decoding with unicode_internal segfaults on UCS-4 builds Initial Comment: On UCS-4 builds, decoding a byte string with the unicode_internal codec doesn't correctly work for code points from 0x80000000 upwards and even segfaults. I have observed the same behaviour on 2.5 from CVS and 2.4.0 on OS X/PowerPC as well as on 2.3.5 on Linux/x86. Here's an example: Python 2.5a0 (#1, Aug 3 2005, 21:34:05) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> "\x7f\xff\xff\xff".decode("unicode_internal") u'\U7fffffff' >>> "\x80\x00\x00\x00".decode("unicode_internal") u'\x00' >>> "\x80\x00\x00\x01".decode("unicode_internal") u'\x01' >>> "\x81\x00\x00\x00".decode("unicode_internal") Segmentation fault On little endian architectures the byte strings must be reversed for the same effect. I'm not sure if I understand what's going on, but I guess there are 2 solution strategies: 1. Make unicode_internal work for any code point up to 0xFFFFFFFF. 2. Make unicode_internal raise a UnicodeDecodeError for anything above 0x10FFFF (== sys.maxunicode for UCS-4 builds). It seems like there are no unicode code points above 0x10FFFF, so the latter solution feels more correct to me, even though it might break backwards compatibility a tiny bit. The unicodeescape codec already does a similar thing: >>> u"\U00110000" UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character ---------------------------------------------------------------------- >Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-19 16:17 Message: Logged In: YES user_id=1317086 I agree about the ifdefs. I'm not sure about how to handle input strings of incorrect length. I guess raising an UnicodeDecodeError is in order. But I think it doesn't make sense to let it pass through the error handler, since the data the handler would see is potentially nonsensical (e.g., the code point value). Can you comment on this? Is it ok to raise a UnicodeDecodeError and skip the error handler here? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-18 22:17 Message: Logged In: YES user_id=89016 The patch has a problem with input strings of a length that is not a multiple of 4, e.g. "\x00".decode("unicode-internal") returns u"" instead of raising an error. Also in a UCS-2 build most of the tests are irrelevant (as it's not possible to create codepoints above 0x10ffff even when using surrogates), so probably they should be ifdef'd out. ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 23:08 Message: Logged In: YES user_id=1317086 Here's the patch with error handler support + test. Again: Please review carefully. ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 18:35 Message: Logged In: YES user_id=1317086 Ah, that PEP clears some things up for me. I will look into it, but I hope you realize this requires tinkering with unicodeobject.c since the error handler code seems to live there. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-05 18:03 Message: Logged In: YES user_id=89016 Your patch doesn't support PEP 293 error handlers. Could you add support for that? ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 16:50 Message: Logged In: YES user_id=1317086 OK, I put something together. Please review carefully as I'm not very familiar with the C API. I have tested this with the CVS HEAD on OS X and Linux. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:41 Message: Logged In: YES user_id=38388 I think solution 2 is the right approach, since UCS-4 only has 0x10FFFF possible code points. Could you provide a patch ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&group_id=5470 From noreply at sourceforge.net Fri Aug 19 17:39:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 19 Aug 2005 08:39:01 -0700 Subject: [ python-Bugs-1251300 ] Decoding with unicode_internal segfaults on UCS-4 builds Message-ID: Bugs item #1251300, was opened at 2005-08-03 21:49 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&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: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nik Haldimann (nhaldimann) Assigned to: M.-A. Lemburg (lemburg) Summary: Decoding with unicode_internal segfaults on UCS-4 builds Initial Comment: On UCS-4 builds, decoding a byte string with the unicode_internal codec doesn't correctly work for code points from 0x80000000 upwards and even segfaults. I have observed the same behaviour on 2.5 from CVS and 2.4.0 on OS X/PowerPC as well as on 2.3.5 on Linux/x86. Here's an example: Python 2.5a0 (#1, Aug 3 2005, 21:34:05) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> "\x7f\xff\xff\xff".decode("unicode_internal") u'\U7fffffff' >>> "\x80\x00\x00\x00".decode("unicode_internal") u'\x00' >>> "\x80\x00\x00\x01".decode("unicode_internal") u'\x01' >>> "\x81\x00\x00\x00".decode("unicode_internal") Segmentation fault On little endian architectures the byte strings must be reversed for the same effect. I'm not sure if I understand what's going on, but I guess there are 2 solution strategies: 1. Make unicode_internal work for any code point up to 0xFFFFFFFF. 2. Make unicode_internal raise a UnicodeDecodeError for anything above 0x10FFFF (== sys.maxunicode for UCS-4 builds). It seems like there are no unicode code points above 0x10FFFF, so the latter solution feels more correct to me, even though it might break backwards compatibility a tiny bit. The unicodeescape codec already does a similar thing: >>> u"\U00110000" UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-08-19 17:39 Message: Logged In: YES user_id=89016 The data the handler sees is nonsensical by definition. ;) To get an idea how to handle an incorrect length, take a look at Objects/unicodeobject.c::PyUnicode_DecodeUTF16Stateful() ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-19 16:17 Message: Logged In: YES user_id=1317086 I agree about the ifdefs. I'm not sure about how to handle input strings of incorrect length. I guess raising an UnicodeDecodeError is in order. But I think it doesn't make sense to let it pass through the error handler, since the data the handler would see is potentially nonsensical (e.g., the code point value). Can you comment on this? Is it ok to raise a UnicodeDecodeError and skip the error handler here? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-18 22:17 Message: Logged In: YES user_id=89016 The patch has a problem with input strings of a length that is not a multiple of 4, e.g. "\x00".decode("unicode-internal") returns u"" instead of raising an error. Also in a UCS-2 build most of the tests are irrelevant (as it's not possible to create codepoints above 0x10ffff even when using surrogates), so probably they should be ifdef'd out. ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 23:08 Message: Logged In: YES user_id=1317086 Here's the patch with error handler support + test. Again: Please review carefully. ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 18:35 Message: Logged In: YES user_id=1317086 Ah, that PEP clears some things up for me. I will look into it, but I hope you realize this requires tinkering with unicodeobject.c since the error handler code seems to live there. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-05 18:03 Message: Logged In: YES user_id=89016 Your patch doesn't support PEP 293 error handlers. Could you add support for that? ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 16:50 Message: Logged In: YES user_id=1317086 OK, I put something together. Please review carefully as I'm not very familiar with the C API. I have tested this with the CVS HEAD on OS X and Linux. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:41 Message: Logged In: YES user_id=38388 I think solution 2 is the right approach, since UCS-4 only has 0x10FFFF possible code points. Could you provide a patch ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&group_id=5470 From noreply at sourceforge.net Fri Aug 19 17:45:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 19 Aug 2005 08:45:53 -0700 Subject: [ python-Bugs-1251300 ] Decoding with unicode_internal segfaults on UCS-4 builds Message-ID: Bugs item #1251300, was opened at 2005-08-03 21:49 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&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: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nik Haldimann (nhaldimann) >Assigned to: Walter D?rwald (doerwalter) Summary: Decoding with unicode_internal segfaults on UCS-4 builds Initial Comment: On UCS-4 builds, decoding a byte string with the unicode_internal codec doesn't correctly work for code points from 0x80000000 upwards and even segfaults. I have observed the same behaviour on 2.5 from CVS and 2.4.0 on OS X/PowerPC as well as on 2.3.5 on Linux/x86. Here's an example: Python 2.5a0 (#1, Aug 3 2005, 21:34:05) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> "\x7f\xff\xff\xff".decode("unicode_internal") u'\U7fffffff' >>> "\x80\x00\x00\x00".decode("unicode_internal") u'\x00' >>> "\x80\x00\x00\x01".decode("unicode_internal") u'\x01' >>> "\x81\x00\x00\x00".decode("unicode_internal") Segmentation fault On little endian architectures the byte strings must be reversed for the same effect. I'm not sure if I understand what's going on, but I guess there are 2 solution strategies: 1. Make unicode_internal work for any code point up to 0xFFFFFFFF. 2. Make unicode_internal raise a UnicodeDecodeError for anything above 0x10FFFF (== sys.maxunicode for UCS-4 builds). It seems like there are no unicode code points above 0x10FFFF, so the latter solution feels more correct to me, even though it might break backwards compatibility a tiny bit. The unicodeescape codec already does a similar thing: >>> u"\U00110000" UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-19 17:45 Message: Logged In: YES user_id=38388 Assigning to Walter, the error handler expert :-) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-19 17:39 Message: Logged In: YES user_id=89016 The data the handler sees is nonsensical by definition. ;) To get an idea how to handle an incorrect length, take a look at Objects/unicodeobject.c::PyUnicode_DecodeUTF16Stateful() ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-19 16:17 Message: Logged In: YES user_id=1317086 I agree about the ifdefs. I'm not sure about how to handle input strings of incorrect length. I guess raising an UnicodeDecodeError is in order. But I think it doesn't make sense to let it pass through the error handler, since the data the handler would see is potentially nonsensical (e.g., the code point value). Can you comment on this? Is it ok to raise a UnicodeDecodeError and skip the error handler here? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-18 22:17 Message: Logged In: YES user_id=89016 The patch has a problem with input strings of a length that is not a multiple of 4, e.g. "\x00".decode("unicode-internal") returns u"" instead of raising an error. Also in a UCS-2 build most of the tests are irrelevant (as it's not possible to create codepoints above 0x10ffff even when using surrogates), so probably they should be ifdef'd out. ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 23:08 Message: Logged In: YES user_id=1317086 Here's the patch with error handler support + test. Again: Please review carefully. ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 18:35 Message: Logged In: YES user_id=1317086 Ah, that PEP clears some things up for me. I will look into it, but I hope you realize this requires tinkering with unicodeobject.c since the error handler code seems to live there. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-05 18:03 Message: Logged In: YES user_id=89016 Your patch doesn't support PEP 293 error handlers. Could you add support for that? ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 16:50 Message: Logged In: YES user_id=1317086 OK, I put something together. Please review carefully as I'm not very familiar with the C API. I have tested this with the CVS HEAD on OS X and Linux. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:41 Message: Logged In: YES user_id=38388 I think solution 2 is the right approach, since UCS-4 only has 0x10FFFF possible code points. Could you provide a patch ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&group_id=5470 From noreply at sourceforge.net Fri Aug 19 18:16:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 19 Aug 2005 09:16:38 -0700 Subject: [ python-Bugs-1263656 ] IDLE on Mac Message-ID: Bugs item #1263656, was opened at 2005-08-18 22:35 Message generated for change (Comment added) made by bsherwood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263656&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: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE on Mac Initial Comment: Copying code from some browsers into IDLE on the Mac can leave the file with only \r (13) at the ends of lines (Safari doesn't seem to have this problem). Then checksyntax() in ScriptBinding.py fails to convert these into \n (10), and compile() fails. The effect is that a program which Python is willing to run gets a syntax error in IDLE. I think the fix is in checksyntax() to add after source = re.sub(r"\r\n", "\n", source) the following statement, which converts unaccompanied \r's into \n's:: source = re.sub(r"\r", "\n", source) I've tried this and it works, but someone with a better overview of end-of-line issues in Python should think through whether this is the appropriate fix. ---------------------------------------------------------------------- >Comment By: Bruce Sherwood (bsherwood) Date: 2005-08-19 12:16 Message: Logged In: YES user_id=34881 I should have said that this is in the environment of running IDLE on Mac OSX 10.4 under X11, using the fink distribution. I should also say that there seem to be issues not only of compiling but also of editing/display. In a browser, click on a .py file, select all the text, copy, paste into IDLE. With Safari, it looks right and it runs. With NetScape, it displays all on one line, and it doesn't run (syntax error). I haven't studied the actual code to see what if anything IDLE does to attempt to detect the nature of text pasted into an edit window, but clearly it's different coming from two popular browsers. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2005-08-19 00:23 Message: Logged In: YES user_id=34881 A footnote: Now I don't understand why the substitution searches for r"\r\n", since this would seem to be the raw string which represents slash, r, slash, n, not the two-character string "\r\n"....?? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263656&group_id=5470 From noreply at sourceforge.net Fri Aug 19 19:31:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 19 Aug 2005 10:31:34 -0700 Subject: [ python-Bugs-1264168 ] PyArg_ParseTupleAndKeywords doesn't handle I format correctl Message-ID: Bugs item #1264168, was opened at 2005-08-19 10:31 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=1264168&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: None Status: Open Resolution: None Priority: 5 Submitted By: John Finlay (finlay648) Assigned to: Nobody/Anonymous (nobody) Summary: PyArg_ParseTupleAndKeywords doesn't handle I format correctl Initial Comment: PyArg_ParseTupleAndKeywords fails with the message; "...impossible" when parsing an optional keyword param using "I" format. Using Python 2.3.5 but also observed in Python 2.4.x The problem is a missing "I" handler in the skipitem function. I've attached a proposed patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1264168&group_id=5470 From noreply at sourceforge.net Fri Aug 19 20:18:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 19 Aug 2005 11:18:02 -0700 Subject: [ python-Bugs-1264168 ] PyArg_ParseTupleAndKeywords doesn't handle I format correctl Message-ID: Bugs item #1264168, was opened at 2005-08-19 19:31 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1264168&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: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: John Finlay (finlay648) Assigned to: Nobody/Anonymous (nobody) Summary: PyArg_ParseTupleAndKeywords doesn't handle I format correctl Initial Comment: PyArg_ParseTupleAndKeywords fails with the message; "...impossible" when parsing an optional keyword param using "I" format. Using Python 2.3.5 but also observed in Python 2.4.x The problem is a missing "I" handler in the skipitem function. I've attached a proposed patch. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-19 20:18 Message: Logged In: YES user_id=1188172 Duplicate of #893549. See patch #1212928 to fix all missing format codes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1264168&group_id=5470 From noreply at sourceforge.net Fri Aug 19 20:40:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 19 Aug 2005 11:40:33 -0700 Subject: [ python-Bugs-1264168 ] PyArg_ParseTupleAndKeywords doesn't handle I format correctl Message-ID: Bugs item #1264168, was opened at 2005-08-19 10:31 Message generated for change (Comment added) made by finlay648 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1264168&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: None Status: Closed Resolution: Duplicate Priority: 5 Submitted By: John Finlay (finlay648) Assigned to: Nobody/Anonymous (nobody) Summary: PyArg_ParseTupleAndKeywords doesn't handle I format correctl Initial Comment: PyArg_ParseTupleAndKeywords fails with the message; "...impossible" when parsing an optional keyword param using "I" format. Using Python 2.3.5 but also observed in Python 2.4.x The problem is a missing "I" handler in the skipitem function. I've attached a proposed patch. ---------------------------------------------------------------------- >Comment By: John Finlay (finlay648) Date: 2005-08-19 11:40 Message: Logged In: YES user_id=1331852 And how would one look up a bug by bug number since there appears to be no obvious way to do this. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-19 11:18 Message: Logged In: YES user_id=1188172 Duplicate of #893549. See patch #1212928 to fix all missing format codes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1264168&group_id=5470 From noreply at sourceforge.net Fri Aug 19 20:48:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 19 Aug 2005 11:48:15 -0700 Subject: [ python-Bugs-1264168 ] PyArg_ParseTupleAndKeywords doesn't handle I format correctl Message-ID: Bugs item #1264168, was opened at 2005-08-19 19:31 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1264168&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: None Status: Closed Resolution: Duplicate Priority: 5 Submitted By: John Finlay (finlay648) Assigned to: Nobody/Anonymous (nobody) Summary: PyArg_ParseTupleAndKeywords doesn't handle I format correctl Initial Comment: PyArg_ParseTupleAndKeywords fails with the message; "...impossible" when parsing an optional keyword param using "I" format. Using Python 2.3.5 but also observed in Python 2.4.x The problem is a missing "I" handler in the skipitem function. I've attached a proposed patch. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-19 20:48 Message: Logged In: YES user_id=1188172 Either order the bugs in SF by ID, or use an URL of the form http://www.python.org/sf/ (number without '#') ---------------------------------------------------------------------- Comment By: John Finlay (finlay648) Date: 2005-08-19 20:40 Message: Logged In: YES user_id=1331852 And how would one look up a bug by bug number since there appears to be no obvious way to do this. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-19 20:18 Message: Logged In: YES user_id=1188172 Duplicate of #893549. See patch #1212928 to fix all missing format codes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1264168&group_id=5470 From noreply at sourceforge.net Sat Aug 20 08:17:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 19 Aug 2005 23:17:09 -0700 Subject: [ python-Bugs-1264666 ] PEP 8 uses wrong raise syntax Message-ID: Bugs item #1264666, was opened at 2005-08-20 00:17 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=1264666&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: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 8 uses wrong raise syntax Initial Comment: Despite the recommendation in "Programming Recommendations" to use:: raise ValueError('message') instead of:: raise ValueError, 'message' the PEP itself uses the second form under the "Maximum Line Length" section:: raise ValueError, "sorry, you lose" ... raise ValueError, "I don't think so" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1264666&group_id=5470 From noreply at sourceforge.net Sat Aug 20 15:51:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 20 Aug 2005 06:51:57 -0700 Subject: [ python-Bugs-1264666 ] PEP 8 uses wrong raise syntax Message-ID: Bugs item #1264666, was opened at 2005-08-20 02:17 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1264666&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Steven Bethard (bediviere) >Assigned to: David Goodger (goodger) Summary: PEP 8 uses wrong raise syntax Initial Comment: Despite the recommendation in "Programming Recommendations" to use:: raise ValueError('message') instead of:: raise ValueError, 'message' the PEP itself uses the second form under the "Maximum Line Length" section:: raise ValueError, "sorry, you lose" ... raise ValueError, "I don't think so" ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2005-08-20 09:51 Message: Logged In: YES user_id=7733 fixed in revision 1.27 Thanks for the heads-up! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1264666&group_id=5470 From noreply at sourceforge.net Sat Aug 20 23:30:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 20 Aug 2005 14:30:20 -0700 Subject: [ python-Bugs-1265100 ] sequence slicing documentation incomplete Message-ID: Bugs item #1265100, was opened at 2005-08-20 15:30 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=1265100&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: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: sequence slicing documentation incomplete Initial Comment: Here's what points (3) and (5) of the Sequence Types[1] documentation say now: """ (3) If i or j is negative, the index is relative to the end of the string: len(s) + i or len(s) + j is substituted. But note that -0 is still 0. ... (5) The slice of s from i to j with step k is defined as the sequence of items with index x = i + n*k such that $0 \leq n < \frac{j-i}{k}$. In other words, the indices are i, i+k, i+2*k, i+3*k and so on, stopping when j is reached (but never including j). If i or j is greater than len(s), use len(s). If i or j are omitted then they become ``end'' values (which end depends on the sign of k). Note, k cannot be zero. """ I'd like to replace that second-to-last sentence in point (5), which uses the vague word "end'' in its description, with something more explicit. I'd like it to read something like: """ If k is positive and i or j is omitted, they will be replaced with 0 and len(s) respectively. If k is negative and i or j is omitted, they will be replaced with -1 and -len(s)-1 respectively. Note that these replacements happen before the rule from point (3) is applied. """ I'd also like to put an example with point (5) to show this behavior in action. Something like: """ So for example:: >>> seq = 'abcde' >>> len(seq) 5 >>> 'edc' == seq[:1:-1] == seq[-1:1:-1] True >>> 'ca' == seq[2::-2] == seq[2:-5-1:-2] True Note however that manually applying the rule from point (3) (adding len(s) to any i or j that is negative) works for i, but does not work for j:: >>> seq[5-1:1:-1] 'edc' >>> seq[2:-1:-2] '' This is because Python sees the -1 in the j position and applies the rule from point (3) again. """ One of the motivations for this patch is to be able to explain the difference in behavior between sequence slicing and slice.indices(), e.g. >>> seq[::-2] 'eca' >>> slice(None, None, -2).indices(5) (4, -1, -2) >>> seq[4:-1:-2] '' Right now, I think the documentation is too vague to be able to make it clear why slices behave differently. If this patch is accepted, I'll work on a patch for slice objects that explains the differences. [1] http://docs.python.org/lib/typesseq.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1265100&group_id=5470 From noreply at sourceforge.net Sat Aug 20 23:31:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 20 Aug 2005 14:31:43 -0700 Subject: [ python-Bugs-1265100 ] sequence slicing documentation incomplete Message-ID: Bugs item #1265100, was opened at 2005-08-20 15:30 Message generated for change (Settings changed) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1265100&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: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: sequence slicing documentation incomplete Initial Comment: Here's what points (3) and (5) of the Sequence Types[1] documentation say now: """ (3) If i or j is negative, the index is relative to the end of the string: len(s) + i or len(s) + j is substituted. But note that -0 is still 0. ... (5) The slice of s from i to j with step k is defined as the sequence of items with index x = i + n*k such that $0 \leq n < \frac{j-i}{k}$. In other words, the indices are i, i+k, i+2*k, i+3*k and so on, stopping when j is reached (but never including j). If i or j is greater than len(s), use len(s). If i or j are omitted then they become ``end'' values (which end depends on the sign of k). Note, k cannot be zero. """ I'd like to replace that second-to-last sentence in point (5), which uses the vague word "end'' in its description, with something more explicit. I'd like it to read something like: """ If k is positive and i or j is omitted, they will be replaced with 0 and len(s) respectively. If k is negative and i or j is omitted, they will be replaced with -1 and -len(s)-1 respectively. Note that these replacements happen before the rule from point (3) is applied. """ I'd also like to put an example with point (5) to show this behavior in action. Something like: """ So for example:: >>> seq = 'abcde' >>> len(seq) 5 >>> 'edc' == seq[:1:-1] == seq[-1:1:-1] True >>> 'ca' == seq[2::-2] == seq[2:-5-1:-2] True Note however that manually applying the rule from point (3) (adding len(s) to any i or j that is negative) works for i, but does not work for j:: >>> seq[5-1:1:-1] 'edc' >>> seq[2:-1:-2] '' This is because Python sees the -1 in the j position and applies the rule from point (3) again. """ One of the motivations for this patch is to be able to explain the difference in behavior between sequence slicing and slice.indices(), e.g. >>> seq[::-2] 'eca' >>> slice(None, None, -2).indices(5) (4, -1, -2) >>> seq[4:-1:-2] '' Right now, I think the documentation is too vague to be able to make it clear why slices behave differently. If this patch is accepted, I'll work on a patch for slice objects that explains the differences. [1] http://docs.python.org/lib/typesseq.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1265100&group_id=5470 From noreply at sourceforge.net Sat Aug 20 23:31:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 20 Aug 2005 14:31:58 -0700 Subject: [ python-Bugs-1265100 ] sequence slicing documentation incomplete Message-ID: Bugs item #1265100, was opened at 2005-08-20 15:30 Message generated for change (Settings changed) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1265100&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: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: sequence slicing documentation incomplete Initial Comment: Here's what points (3) and (5) of the Sequence Types[1] documentation say now: """ (3) If i or j is negative, the index is relative to the end of the string: len(s) + i or len(s) + j is substituted. But note that -0 is still 0. ... (5) The slice of s from i to j with step k is defined as the sequence of items with index x = i + n*k such that $0 \leq n < \frac{j-i}{k}$. In other words, the indices are i, i+k, i+2*k, i+3*k and so on, stopping when j is reached (but never including j). If i or j is greater than len(s), use len(s). If i or j are omitted then they become ``end'' values (which end depends on the sign of k). Note, k cannot be zero. """ I'd like to replace that second-to-last sentence in point (5), which uses the vague word "end'' in its description, with something more explicit. I'd like it to read something like: """ If k is positive and i or j is omitted, they will be replaced with 0 and len(s) respectively. If k is negative and i or j is omitted, they will be replaced with -1 and -len(s)-1 respectively. Note that these replacements happen before the rule from point (3) is applied. """ I'd also like to put an example with point (5) to show this behavior in action. Something like: """ So for example:: >>> seq = 'abcde' >>> len(seq) 5 >>> 'edc' == seq[:1:-1] == seq[-1:1:-1] True >>> 'ca' == seq[2::-2] == seq[2:-5-1:-2] True Note however that manually applying the rule from point (3) (adding len(s) to any i or j that is negative) works for i, but does not work for j:: >>> seq[5-1:1:-1] 'edc' >>> seq[2:-1:-2] '' This is because Python sees the -1 in the j position and applies the rule from point (3) again. """ One of the motivations for this patch is to be able to explain the difference in behavior between sequence slicing and slice.indices(), e.g. >>> seq[::-2] 'eca' >>> slice(None, None, -2).indices(5) (4, -1, -2) >>> seq[4:-1:-2] '' Right now, I think the documentation is too vague to be able to make it clear why slices behave differently. If this patch is accepted, I'll work on a patch for slice objects that explains the differences. [1] http://docs.python.org/lib/typesseq.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1265100&group_id=5470 From noreply at sourceforge.net Sun Aug 21 11:29:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 21 Aug 2005 02:29:49 -0700 Subject: [ python-Bugs-1265100 ] sequence slicing documentation incomplete Message-ID: Bugs item #1265100, was opened at 2005-08-20 16:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1265100&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: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: sequence slicing documentation incomplete Initial Comment: Here's what points (3) and (5) of the Sequence Types[1] documentation say now: """ (3) If i or j is negative, the index is relative to the end of the string: len(s) + i or len(s) + j is substituted. But note that -0 is still 0. ... (5) The slice of s from i to j with step k is defined as the sequence of items with index x = i + n*k such that $0 \leq n < \frac{j-i}{k}$. In other words, the indices are i, i+k, i+2*k, i+3*k and so on, stopping when j is reached (but never including j). If i or j is greater than len(s), use len(s). If i or j are omitted then they become ``end'' values (which end depends on the sign of k). Note, k cannot be zero. """ I'd like to replace that second-to-last sentence in point (5), which uses the vague word "end'' in its description, with something more explicit. I'd like it to read something like: """ If k is positive and i or j is omitted, they will be replaced with 0 and len(s) respectively. If k is negative and i or j is omitted, they will be replaced with -1 and -len(s)-1 respectively. Note that these replacements happen before the rule from point (3) is applied. """ I'd also like to put an example with point (5) to show this behavior in action. Something like: """ So for example:: >>> seq = 'abcde' >>> len(seq) 5 >>> 'edc' == seq[:1:-1] == seq[-1:1:-1] True >>> 'ca' == seq[2::-2] == seq[2:-5-1:-2] True Note however that manually applying the rule from point (3) (adding len(s) to any i or j that is negative) works for i, but does not work for j:: >>> seq[5-1:1:-1] 'edc' >>> seq[2:-1:-2] '' This is because Python sees the -1 in the j position and applies the rule from point (3) again. """ One of the motivations for this patch is to be able to explain the difference in behavior between sequence slicing and slice.indices(), e.g. >>> seq[::-2] 'eca' >>> slice(None, None, -2).indices(5) (4, -1, -2) >>> seq[4:-1:-2] '' Right now, I think the documentation is too vague to be able to make it clear why slices behave differently. If this patch is accepted, I'll work on a patch for slice objects that explains the differences. [1] http://docs.python.org/lib/typesseq.html ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-21 04:29 Message: Logged In: YES user_id=80475 -0 The docs read better with "vague" words like "end". Making the description more mathematical may make it more precise but will also make it harder to just read and understand. The wording suggested above is fathomable only after you already understand how slicing works. It is the "vague" words that help achieve the understanding in the first place. Also, I do not want to clutter this section with examples intended to compare and contrast slices versus slice.indices. It would be okay to add a brief comparative example to the docs for slice.indices(). Understanding the latter is aided by a comparison. In contrast, you can get pretty good with slices and know nothing about slice.indices() which is a somewhat challenging method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1265100&group_id=5470 From noreply at sourceforge.net Sun Aug 21 13:10:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 21 Aug 2005 04:10:13 -0700 Subject: [ python-Bugs-1242657 ] list(obj) can swallow KeyboardInterrupt Message-ID: Bugs item #1242657, was opened at 2005-07-21 17:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1242657&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Steve Alexander (stevea_zope) Assigned to: Raymond Hettinger (rhettinger) Summary: list(obj) can swallow KeyboardInterrupt Initial Comment: The example below shows that list(f) swallows the KeyboardInterrupt. It swallows any other exception too, such as MemoryError or application-specific ConflictErrors. I think the "get the length of the object" optimisation should catch only AttributeError and TypeError. >>> class F(object): ... def __iter__(self): ... yield 23 ... def __len__(self): ... print "len called. raising Keyboard Interrupt." ... raise KeyboardInterrupt ... >>> f = F() >>> list(f) len called. raising Keyboard Interrupt. [23] ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-21 06:10 Message: Logged In: YES user_id=80475 Okay, fixed in several places. This little fragment occurred in a number of places including code listextend(), map(), zip(), filter(), and PySequence_Tuple(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1242657&group_id=5470 From noreply at sourceforge.net Sun Aug 21 13:28:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 21 Aug 2005 04:28:04 -0700 Subject: [ python-Bugs-1249837 ] container methods raise KeyError not IndexError Message-ID: Bugs item #1249837, was opened at 2005-08-01 15:47 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249837&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: Fixed Priority: 5 Submitted By: Wilfredo Sanchez (wsanchez) Assigned to: Raymond Hettinger (rhettinger) Summary: container methods raise KeyError not IndexError Initial Comment: See: http://www.python.org/doc/2.3.5/ref/sequence-types.html, which says, for example, that __getitem__(self, key) should raise an IndexError if key is not in the container. However, built-in dicts raise KeyError instead, and http:// www.python.org/doc/2.3.5/lib/module-exceptions.html#l2h-289 implies that this is the correct behavior. This appears to be incorrect in the current documentation as well as in the 2.3.5 docs. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-21 06:28 Message: Logged In: YES user_id=80475 Okay. Fixed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-01 16:54 Message: Logged In: YES user_id=80475 Both the behavior and the docs are correct. However, the docs are not especially clear on this point. Will add a clarifying note that KeyError is the appropriate error for mapping types when the key is not found. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249837&group_id=5470 From noreply at sourceforge.net Sun Aug 21 13:35:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 21 Aug 2005 04:35:24 -0700 Subject: [ python-Bugs-1207379 ] class property fset not working Message-ID: Bugs item #1207379, was opened at 2005-05-23 17:02 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&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: None Status: Open Resolution: None Priority: 5 Submitted By: Master_Jaf (master_jaf) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: class property fset not working Initial Comment: Classes which are not instantiated from 'object', containing properties, are not working as expected. The GET method is working but not the SET method. Tested with python 2.4.1 und 2.3.5. See sample code file. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-21 06:35 Message: Logged In: YES user_id=80475 Stay close to the definition in the tutorial's glossary: """ new-style class Any class that inherits from object. This includes all built-in types like list and dict. Only new-style classes can use Python's newer, versatile features like __slots__, descriptors, properties, __getattribute__(), class methods, and static methods. """ Also, the 2.2 comment should be in standard form markup: \versionadded{} "classes" ==> "class" Overall, -0 on the update. Ideally, the tutorial should be kept free of the more advanced concepts like properties, static methods, descriptors, and whatnot. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 05:27 Message: Logged In: YES user_id=1188172 Attaching a patch for the Tutorial. It adds the following sentence: +Note that with Python 2.2, a new kind of classes was introduced: +A class deriving from \class{object} is called a \emph{new-style class}. +The differences to classic classes are mostly internal, but there are +some features (like properties and static methods) that are only +available for new-style classes. + ---------------------------------------------------------------------- Comment By: Master_Jaf (master_jaf) Date: 2005-05-26 13:59 Message: Logged In: YES user_id=1140154 >From my point of view (I'm just learning Python) there is only a simple difference between old and new style classes, just the (object) while defining a class. For sure, we can close this. My questions were answered :-) So my suggestions for adding info to the documentation: "Python Tutorial": Chap. 9.3., ex. With Python 2.2 new style classes were introduced. These new style classes are inherited from 'object' base class and supporting newer features like properties, slots etc.. It is recommended to use new style classes. "Python Library Reference": Chap. 2.1 Built-in Functions, ex. property([fget[, fset[, fdel[, doc]]]]) [....] New in Python 2.2. Properties only can applied to new style classes. See also "D. Glossary" -> new style classes for more details. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 11:37 Message: Logged In: YES user_id=593130 For people who learned Python with old-style classes, it is 'obvious' that properties are a new addition that came with and work with new-style classes. Can you suggest specific places in the docs where clarification could be made? Or should be close this? (I suspect that setting is more complicated than getting but would not have expected even the get method to work.) ---------------------------------------------------------------------- Comment By: Master_Jaf (master_jaf) Date: 2005-05-24 07:27 Message: Logged In: YES user_id=1140154 After reading some more documentation I've found at Python Tutorial "D. Glossary" more hints. <cite> Any class that inherits from object. This includes all built-in types like list and dict. Only new-style classes can use Python's newer, versatile features like __slots__, descriptors, properties, __getattribute__(), class methods, and static methods. </cite> Fine. OK, understood.. I'm tending to agree with mwh's opinion, that this is a documentation bug, although I don't fully understand why the GET descriptor is working but unlikly not the SET descriptor. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-24 02:58 Message: Logged In: YES user_id=6656 At the very limit, this is a documentation bug. Why did you think properties could be attached to old-style classes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470 From noreply at sourceforge.net Sun Aug 21 14:00:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 21 Aug 2005 05:00:28 -0700 Subject: [ python-Bugs-1121416 ] zip incorrectly and incompletely documented Message-ID: Bugs item #1121416, was opened at 2005-02-12 12:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&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: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Alan (aisaac0) Assigned to: Raymond Hettinger (rhettinger) Summary: zip incorrectly and incompletely documented Initial Comment: See the zip documentation: http://www.python.org/dev/doc/devel/lib/built-in-funcs.html i. documentation refers to sequences not to iterables ii. The other problem is easier to explain by example. Let it=iter([1,2,3,4]). What is the result of zip(*[it]*2)? The current answer is: [(1,2),(3,4)], but it is impossible to determine this from the docs, which would allow [(1,3),(2,4)] instead (or indeed other possibilities). The example expresses the solution to an actual need, so the behavior should be documented or warned against, I believe. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-21 07:00 Message: Logged In: YES user_id=80475 Changed sequences to iterables. Left the evaluation order as an unspecified, implementation specific detail. ---------------------------------------------------------------------- Comment By: Alan (aisaac0) Date: 2005-03-06 16:36 Message: Logged In: YES user_id=1025672 > The OP's problem should be left as a code smell indicating a misuse of functionals. Left how? I did not propose any change in behavior or intent. I only asked that the behavior shd either i. be determinate and documented, or ii. be acknowledged in the docs as indeterminate as a caution not to rely on current behavior which seems natural but I take it not guaranteed. (Ideally the docs would link to a helpful explanation of why it is appropriate not to guarantee the behavior.) The fact that this question came up is evidence, IMO, that the docs are incomplete. (I'm not the only one who was puzzled.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-16 20:10 Message: Logged In: YES user_id=80475 The first sentence becomes even less clear with the "in the same order" wording. The note about truncating to the shortest sequence length is essential and should not have been dropped. The py2.4 change note is in a standard form (\versionchanged{} following the explanation of current behavior) and should not have been altered. The part that addresses the OP's concern is too specific to the his one example and is unclear unless you know about that example. The wording is discomforting, doesn't add new information, and is somewhat not obvious in its meaning. I suggest simply changing "sequence" to "iterable". There is no sense in stating that the order of combination is undefined. It doesn't help with the OP's original desire to be able to predict the outcome of the example. However, it does have the negative effect of making a person question whether they've understood the preceding description of what actually zip() does do. zip() is about lockstep iteration and the docs should serve those users as straight-forwardly as possible. The OP's issue on the other hand only comes up when trying funky iterator magic -- adding a sentence about undefined ordering doesn't help one bit. There is a lesson in all this. These tools were borrowed from the world of functional programming which is all about programming that is free of side-effects. The OP's problem should be left as a code smell indicating a misuse of functionals. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 19:03 Message: Logged In: YES user_id=593130 I agree that the zip doc needs improvement. Confusion will continue until it is. Here is my suggested rewrite: ------------------------------------------------------------------- zip([iterable1, ...]) Return a list of tuples, where the i-th tuple contains the i-th element from each input in the same order as the inputs. With no arguments, return an empty list (before 2.4, a TypeError was raised instead.) With a single input, return a list of 1-tuples. With multiple inputs, the output length is that of the shorted input. When multiple input lengths are equal, zip(i1, ...) is similar to map(None, i1, ...), but there is no padding when otherwise. The result of zipping a volatile iterable with itself is undefined. New in 2.0. ------------------------------------------------------------------- There you have it. More information is about 15% fewer words. The reduction came from greatly condensing the overwordy sentence about obsolete behavior into a parenthetical comment. For comparison, here is the current version. ------------------------------------------------------------------- zip( [seq1, ...]) This function returns a list of tuples, where the i-th tuple contains the i-th element from each of the argument sequences. The returned list is truncated in length to the length of the shortest argument sequence. When there are multiple argument sequences which are all of the same length, zip() is similar to map() with an initial argument of None. With a single sequence argument, it returns a list of 1- tuples. With no arguments, it returns an empty list. New in version 2.0. Changed in version 2.4: Formerly, zip() required at least one argument and zip() raised a TypeError instead of returning an empty list.. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-12 21:25 Message: Logged In: YES user_id=1038590 The generator in the previous comment was incorrect (tuple swallows the StopIteration, so it never terminates). Try this instead: def partition(iterable, part_len): itr = iter(iterable) while 1: item = tuple(islice(itr, part_len)) if len(item) < part_len: raise StopIteration yield item ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-12 20:30 Message: Logged In: YES user_id=1038590 Raymond's point about opaqueness is well-taken, since the given partitioning behaviour in the example was actually what was intended (I was part of the relevant c.l.p discussion). For future reference, the reliable approach is to use a generator function instead: from itertools import islice def partition(iterable, part_len): itr = iter(iterable) while 1: yield tuple(islice(itr, part_len)) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-12 14:50 Message: Logged In: YES user_id=80475 The problem with your example does not lie with zip(). Instead, there is a misunderstanding of iter() and how iterators are consumed. Instead of iter(), the correct function is itertools.tee(): >>> zip(*tee([1,2,3,4])) [(1, 1), (2, 2), (3, 3), (4, 4)] Also, stylistically, the zip(*func) approach is too opaque. It is almost always better (at least for other readers and possibly for yourself) to write something more obvious in its intent and operation. List comprehensions and generator expressions are often more clear and easier to write correctly: >>> [(x,x) for x in [1,2,3,4]] [(1, 1), (2, 2), (3, 3), (4, 4)] I do agree that the word sequence should be dropped because it implies that non-sequence iterables are not acceptable as arguments. That's too bad because the word "sequence" seems to help people understand what zip is doing. You're correct that the zip docs do not describe its implementation in such detail as to be able to predict the [(1,2),(3,4)] result. However, that would be an over-specification. That particular result is an implementation specific detail that is subject to change. It probably won't change, but we don't want to encourage people to write code that relies on the specific order of operations within zip(). If someone wants to do something tricky, such as [(1,2),(3,4)], then they are better off writing an explicit loop so that the order of operation is clear both to themselves and to code reviewers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 From noreply at sourceforge.net Sun Aug 21 14:03:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 21 Aug 2005 05:03:10 -0700 Subject: [ python-Bugs-1191043 ] bz2 RuntimeError when decompressing file Message-ID: Bugs item #1191043, was opened at 2005-04-27 09:34 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191043&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Chris AtLee (catlee) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: bz2 RuntimeError when decompressing file Initial Comment: The following code: echo -n Testing123 | bzip2 > test.bz2 python -c "import bz2; lines = bz2.BZ2File('test.bz2').readlines()" produces this output: Traceback (most recent call last): File "", line 1, in ? RuntimeError: wrong sequence of bz2 library commands used Tested on Python 2.4.1 (debian unstable - April 1 2005), and Python 2.3.5 (debian unstable - May 26 2005) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-21 07:03 Message: Logged In: YES user_id=80475 Reinhold, do you want to take this one? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-14 09:55 Message: Logged In: YES user_id=11375 Calling .readline() works fine, though. The problem wasn't apparent with a quick look at the readlines() code. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 07:14 Message: Logged In: YES user_id=80475 Okay, I see. Will look into it. ---------------------------------------------------------------------- Comment By: Chris AtLee (catlee) Date: 2005-04-28 07:00 Message: Logged In: YES user_id=186532 How is test.bz2 not a valid bz2 file? The command line tool "bzcat" or "bunzip2" can operate properly on it. Using BZ2File("test.bz2").read() works properly, it's just the readlines() call that breaks. Try this out: import bz2 bz2.BZ2File("test.bz2","w").write("testing123") # This works fine assert bz2.BZ2File("test.bz2").read() == "testing123" # This raises a RuntimeError assert bz2.BZ2File("test.bz2").readlines() == ["testing123"] ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 02:06 Message: Logged In: YES user_id=80475 The looks like correct behavior to me. The test.bz2 file is not in a valid bz2 format. I suspect that you've misread the BZ2File API which is intended for reading and writing uncompressed data to and from a file in a bz2 format (where the data is stored in compressed form). If this interpretation of the bug report is correct, please mark as not-a-bug and close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191043&group_id=5470 From noreply at sourceforge.net Sun Aug 21 16:17:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 21 Aug 2005 07:17:05 -0700 Subject: [ python-Bugs-1207379 ] class property fset not working Message-ID: Bugs item #1207379, was opened at 2005-05-24 00:02 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&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: None Status: Open Resolution: None Priority: 5 Submitted By: Master_Jaf (master_jaf) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: class property fset not working Initial Comment: Classes which are not instantiated from 'object', containing properties, are not working as expected. The GET method is working but not the SET method. Tested with python 2.4.1 und 2.3.5. See sample code file. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-21 16:17 Message: Logged In: YES user_id=1188172 What am I to do? Correct the patch and apply, or close this as Rejected? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-21 13:35 Message: Logged In: YES user_id=80475 Stay close to the definition in the tutorial's glossary: """ new-style class Any class that inherits from object. This includes all built-in types like list and dict. Only new-style classes can use Python's newer, versatile features like __slots__, descriptors, properties, __getattribute__(), class methods, and static methods. """ Also, the 2.2 comment should be in standard form markup: \versionadded{} "classes" ==> "class" Overall, -0 on the update. Ideally, the tutorial should be kept free of the more advanced concepts like properties, static methods, descriptors, and whatnot. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 12:27 Message: Logged In: YES user_id=1188172 Attaching a patch for the Tutorial. It adds the following sentence: +Note that with Python 2.2, a new kind of classes was introduced: +A class deriving from \class{object} is called a \emph{new-style class}. +The differences to classic classes are mostly internal, but there are +some features (like properties and static methods) that are only +available for new-style classes. + ---------------------------------------------------------------------- Comment By: Master_Jaf (master_jaf) Date: 2005-05-26 20:59 Message: Logged In: YES user_id=1140154 >From my point of view (I'm just learning Python) there is only a simple difference between old and new style classes, just the (object) while defining a class. For sure, we can close this. My questions were answered :-) So my suggestions for adding info to the documentation: "Python Tutorial": Chap. 9.3., ex. With Python 2.2 new style classes were introduced. These new style classes are inherited from 'object' base class and supporting newer features like properties, slots etc.. It is recommended to use new style classes. "Python Library Reference": Chap. 2.1 Built-in Functions, ex. property([fget[, fset[, fdel[, doc]]]]) [....] New in Python 2.2. Properties only can applied to new style classes. See also "D. Glossary" -> new style classes for more details. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 18:37 Message: Logged In: YES user_id=593130 For people who learned Python with old-style classes, it is 'obvious' that properties are a new addition that came with and work with new-style classes. Can you suggest specific places in the docs where clarification could be made? Or should be close this? (I suspect that setting is more complicated than getting but would not have expected even the get method to work.) ---------------------------------------------------------------------- Comment By: Master_Jaf (master_jaf) Date: 2005-05-24 14:27 Message: Logged In: YES user_id=1140154 After reading some more documentation I've found at Python Tutorial "D. Glossary" more hints. <cite> Any class that inherits from object. This includes all built-in types like list and dict. Only new-style classes can use Python's newer, versatile features like __slots__, descriptors, properties, __getattribute__(), class methods, and static methods. </cite> Fine. OK, understood.. I'm tending to agree with mwh's opinion, that this is a documentation bug, although I don't fully understand why the GET descriptor is working but unlikly not the SET descriptor. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-24 09:58 Message: Logged In: YES user_id=6656 At the very limit, this is a documentation bug. Why did you think properties could be attached to old-style classes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470 From noreply at sourceforge.net Sun Aug 21 16:19:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 21 Aug 2005 07:19:11 -0700 Subject: [ python-Bugs-1191043 ] bz2 RuntimeError when decompressing file Message-ID: Bugs item #1191043, was opened at 2005-04-27 16:34 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191043&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Chris AtLee (catlee) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: bz2 RuntimeError when decompressing file Initial Comment: The following code: echo -n Testing123 | bzip2 > test.bz2 python -c "import bz2; lines = bz2.BZ2File('test.bz2').readlines()" produces this output: Traceback (most recent call last): File "", line 1, in ? RuntimeError: wrong sequence of bz2 library commands used Tested on Python 2.4.1 (debian unstable - April 1 2005), and Python 2.3.5 (debian unstable - May 26 2005) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-21 16:19 Message: Logged In: YES user_id=1188172 Fixed, also for xreadlines(). Problem was that the code, if there were no newlines in a chunk read from the file, assumed that the buffer was too small. Modules/bz2module.c r1.25 Lib/test/test_bz2.py r1.18 Please review the fix! ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-21 14:03 Message: Logged In: YES user_id=80475 Reinhold, do you want to take this one? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-14 16:55 Message: Logged In: YES user_id=11375 Calling .readline() works fine, though. The problem wasn't apparent with a quick look at the readlines() code. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 14:14 Message: Logged In: YES user_id=80475 Okay, I see. Will look into it. ---------------------------------------------------------------------- Comment By: Chris AtLee (catlee) Date: 2005-04-28 14:00 Message: Logged In: YES user_id=186532 How is test.bz2 not a valid bz2 file? The command line tool "bzcat" or "bunzip2" can operate properly on it. Using BZ2File("test.bz2").read() works properly, it's just the readlines() call that breaks. Try this out: import bz2 bz2.BZ2File("test.bz2","w").write("testing123") # This works fine assert bz2.BZ2File("test.bz2").read() == "testing123" # This raises a RuntimeError assert bz2.BZ2File("test.bz2").readlines() == ["testing123"] ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 09:06 Message: Logged In: YES user_id=80475 The looks like correct behavior to me. The test.bz2 file is not in a valid bz2 format. I suspect that you've misread the BZ2File API which is intended for reading and writing uncompressed data to and from a file in a bz2 format (where the data is stored in compressed form). If this interpretation of the bug report is correct, please mark as not-a-bug and close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191043&group_id=5470 From noreply at sourceforge.net Sun Aug 21 20:57:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 21 Aug 2005 11:57:26 -0700 Subject: [ python-Feature Requests-983069 ] md5 and sha1 modules should use openssl implementation Message-ID: Feature Requests item #983069, was opened at 2004-06-30 15:50 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=983069&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: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Nobody/Anonymous (nobody) Summary: md5 and sha1 modules should use openssl implementation Initial Comment: the MD5 and SHA-1 modules should use the OpenSSL library to perform the hashing when it is available (always these days; python ships with basic ssl socket support using openssl). OpenSSL includes and keeps up with highly optimized versions of the hash algorithms for various architectures. They should always perform the same or better than the python shamodule and md5module implementations. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2005-08-21 11:57 Message: Logged In: YES user_id=413 hashlib module supporting this has been committed to python cvs head. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=983069&group_id=5470 From noreply at sourceforge.net Sun Aug 21 22:55:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 21 Aug 2005 13:55:57 -0700 Subject: [ python-Bugs-1207379 ] class property fset not working Message-ID: Bugs item #1207379, was opened at 2005-05-24 00:02 Message generated for change (Comment added) made by master_jaf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&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: None Status: Open Resolution: None Priority: 5 Submitted By: Master_Jaf (master_jaf) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: class property fset not working Initial Comment: Classes which are not instantiated from 'object', containing properties, are not working as expected. The GET method is working but not the SET method. Tested with python 2.4.1 und 2.3.5. See sample code file. ---------------------------------------------------------------------- >Comment By: Master_Jaf (master_jaf) Date: 2005-08-21 22:55 Message: Logged In: YES user_id=1140154 I agree with rhettinger, that there is no need to put advanced things like properties in the tutorial. But I still think, that the property explanation in "Python Lib. Ref." could be a bit more precise. IMHO it's not enough to say "Return a property attribute for new-style classes..." because it does not prohibit explicitly the usage in "old style classes". Suggestion: "Python Library Reference": Chap. 2.1 Built-in Functions, ex. property([fget[, fset[, fdel[, doc]]]]) [....] New in Python 2.2. Properties only can be applied to new style classes. See also "D. Glossary" -> new style classes for more details. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-21 16:17 Message: Logged In: YES user_id=1188172 What am I to do? Correct the patch and apply, or close this as Rejected? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-21 13:35 Message: Logged In: YES user_id=80475 Stay close to the definition in the tutorial's glossary: """ new-style class Any class that inherits from object. This includes all built-in types like list and dict. Only new-style classes can use Python's newer, versatile features like __slots__, descriptors, properties, __getattribute__(), class methods, and static methods. """ Also, the 2.2 comment should be in standard form markup: \versionadded{} "classes" ==> "class" Overall, -0 on the update. Ideally, the tutorial should be kept free of the more advanced concepts like properties, static methods, descriptors, and whatnot. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 12:27 Message: Logged In: YES user_id=1188172 Attaching a patch for the Tutorial. It adds the following sentence: +Note that with Python 2.2, a new kind of classes was introduced: +A class deriving from \class{object} is called a \emph{new-style class}. +The differences to classic classes are mostly internal, but there are +some features (like properties and static methods) that are only +available for new-style classes. + ---------------------------------------------------------------------- Comment By: Master_Jaf (master_jaf) Date: 2005-05-26 20:59 Message: Logged In: YES user_id=1140154 >From my point of view (I'm just learning Python) there is only a simple difference between old and new style classes, just the (object) while defining a class. For sure, we can close this. My questions were answered :-) So my suggestions for adding info to the documentation: "Python Tutorial": Chap. 9.3., ex. With Python 2.2 new style classes were introduced. These new style classes are inherited from 'object' base class and supporting newer features like properties, slots etc.. It is recommended to use new style classes. "Python Library Reference": Chap. 2.1 Built-in Functions, ex. property([fget[, fset[, fdel[, doc]]]]) [....] New in Python 2.2. Properties only can applied to new style classes. See also "D. Glossary" -> new style classes for more details. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 18:37 Message: Logged In: YES user_id=593130 For people who learned Python with old-style classes, it is 'obvious' that properties are a new addition that came with and work with new-style classes. Can you suggest specific places in the docs where clarification could be made? Or should be close this? (I suspect that setting is more complicated than getting but would not have expected even the get method to work.) ---------------------------------------------------------------------- Comment By: Master_Jaf (master_jaf) Date: 2005-05-24 14:27 Message: Logged In: YES user_id=1140154 After reading some more documentation I've found at Python Tutorial "D. Glossary" more hints. <cite> Any class that inherits from object. This includes all built-in types like list and dict. Only new-style classes can use Python's newer, versatile features like __slots__, descriptors, properties, __getattribute__(), class methods, and static methods. </cite> Fine. OK, understood.. I'm tending to agree with mwh's opinion, that this is a documentation bug, although I don't fully understand why the GET descriptor is working but unlikly not the SET descriptor. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-24 09:58 Message: Logged In: YES user_id=6656 At the very limit, this is a documentation bug. Why did you think properties could be attached to old-style classes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&group_id=5470 From noreply at sourceforge.net Mon Aug 22 17:21:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 22 Aug 2005 08:21:47 -0700 Subject: [ python-Bugs-1266283 ] lexists() is not exported from os.path Message-ID: Bugs item #1266283, was opened at 2005-08-22 15:21 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=1266283&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: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Blais (blais) Assigned to: Nobody/Anonymous (nobody) Summary: lexists() is not exported from os.path Initial Comment: I'm not quite sure if this is desired, but looking at posixpath.py it looks like a bug: lexists() is not in __all__, and so from os.path import * ... lexists(...) does not work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1266283&group_id=5470 From noreply at sourceforge.net Mon Aug 22 17:43:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 22 Aug 2005 08:43:26 -0700 Subject: [ python-Bugs-1266296 ] Mistakes in decimal.Context.subtract documentation Message-ID: Bugs item #1266296, was opened at 2005-08-22 10:43 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=1266296&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: Jim Sizelove (jsizelove) Assigned to: Nobody/Anonymous (nobody) Summary: Mistakes in decimal.Context.subtract documentation Initial Comment: The subtract method of the decimal.Context object is misspelled as substract in the online html documentation for the decimal module, section 5.6.3. At the Python interactive prompt: >>> import decimal >>> help(decimal.Context.subtract) Help on method subtract in module decimal: subtract(self, a, b) unbound decimal.Context method Return the sum of the two operands. That description should read: Returns the difference between a and b. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1266296&group_id=5470 From noreply at sourceforge.net Mon Aug 22 20:08:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 22 Aug 2005 11:08:12 -0700 Subject: [ python-Bugs-1266283 ] lexists() is not exported from os.path Message-ID: Bugs item #1266283, was opened at 2005-08-22 17:21 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1266283&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin Blais (blais) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: lexists() is not exported from os.path Initial Comment: I'm not quite sure if this is desired, but looking at posixpath.py it looks like a bug: lexists() is not in __all__, and so from os.path import * ... lexists(...) does not work. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-22 20:08 Message: Logged In: YES user_id=1188172 Thanks for the report, fixed in 2.5 and 2.4 branches as Lib/macpath.py; 1.52; 1.50.2.1 Lib/ntpath.py; 1.63; 1.61.2.1 Lib/os2emxpath.py; 1.15; 1.13.2.1 Lib/posixpath.py; 1.75; 1.73.2.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1266283&group_id=5470 From noreply at sourceforge.net Mon Aug 22 20:27:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 22 Aug 2005 11:27:57 -0700 Subject: [ python-Bugs-1266296 ] Mistakes in decimal.Context.subtract documentation Message-ID: Bugs item #1266296, was opened at 2005-08-23 00:43 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1266296&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: Jim Sizelove (jsizelove) Assigned to: Nobody/Anonymous (nobody) Summary: Mistakes in decimal.Context.subtract documentation Initial Comment: The subtract method of the decimal.Context object is misspelled as substract in the online html documentation for the decimal module, section 5.6.3. At the Python interactive prompt: >>> import decimal >>> help(decimal.Context.subtract) Help on method subtract in module decimal: subtract(self, a, b) unbound decimal.Context method Return the sum of the two operands. That description should read: Returns the difference between a and b. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-08-23 03:27 Message: Logged In: YES user_id=671362 Same here :: ./Misc/cheatsheet: x+y x-y addition, substraction ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1266296&group_id=5470 From noreply at sourceforge.net Mon Aug 22 21:02:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 22 Aug 2005 12:02:27 -0700 Subject: [ python-Bugs-1260171 ] subprocess: more general (non-buffering) communication Message-ID: Bugs item #1260171, was opened at 2005-08-15 12:15 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1260171&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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Ian Bicking (ianbicking) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess: more general (non-buffering) communication Initial Comment: Right now you can use subprocess.Popen.communicate() to make communication with subprocesses much easier and less likely to block than communicating directly with .stdin, .stdout, etc. However, that requires completely buffering the input and output. The functionality of communicate() (which is somewhat complex because of platform issues) could be made more general fairly easily. The current functionality of communicate could then be implemented in terms of that new method. I attached a function I'm using which does that for the posix systems (basically turning Popen's posix communicate into a function with some modifications). Replace "proc" with "self" (and give the function a better name) and you'd have a method. If patch 1175984 was accepted, then this wouldn't be that much of an issue: http://sourceforge.net/tracker/index.php?func=detail&aid=1175984&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-08-22 12:02 Message: Logged In: YES user_id=341410 Would an asynchronous subprocess (which you would poll manually) be better/sufficient? http://python.org/sf/1191964 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1260171&group_id=5470 From noreply at sourceforge.net Mon Aug 22 21:03:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 22 Aug 2005 12:03:11 -0700 Subject: [ python-Bugs-1260171 ] subprocess: more general (non-buffering) communication Message-ID: Bugs item #1260171, was opened at 2005-08-15 12:15 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1260171&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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Ian Bicking (ianbicking) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess: more general (non-buffering) communication Initial Comment: Right now you can use subprocess.Popen.communicate() to make communication with subprocesses much easier and less likely to block than communicating directly with .stdin, .stdout, etc. However, that requires completely buffering the input and output. The functionality of communicate() (which is somewhat complex because of platform issues) could be made more general fairly easily. The current functionality of communicate could then be implemented in terms of that new method. I attached a function I'm using which does that for the posix systems (basically turning Popen's posix communicate into a function with some modifications). Replace "proc" with "self" (and give the function a better name) and you'd have a method. If patch 1175984 was accepted, then this wouldn't be that much of an issue: http://sourceforge.net/tracker/index.php?func=detail&aid=1175984&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-08-22 12:03 Message: Logged In: YES user_id=341410 Also, what you post is not a 'bug', it is a 'feature request'. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-08-22 12:02 Message: Logged In: YES user_id=341410 Would an asynchronous subprocess (which you would poll manually) be better/sufficient? http://python.org/sf/1191964 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1260171&group_id=5470 From noreply at sourceforge.net Mon Aug 22 21:36:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 22 Aug 2005 12:36:15 -0700 Subject: [ python-Bugs-1266296 ] Mistakes in decimal.Context.subtract documentation Message-ID: Bugs item #1266296, was opened at 2005-08-22 17:43 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1266296&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Jim Sizelove (jsizelove) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Mistakes in decimal.Context.subtract documentation Initial Comment: The subtract method of the decimal.Context object is misspelled as substract in the online html documentation for the decimal module, section 5.6.3. At the Python interactive prompt: >>> import decimal >>> help(decimal.Context.subtract) Help on method subtract in module decimal: subtract(self, a, b) unbound decimal.Context method Return the sum of the two operands. That description should read: Returns the difference between a and b. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-22 21:36 Message: Logged In: YES user_id=1188172 Thank you for the report; fixed in 2.5 and 2.4 branches as Doc/lib/libdecimal.tex; 1.29; 1.24.2.4 Lib/decimal.py; 1.39; 1.31.2.5 Misc/cheatsheet; 1.11; 1.10.2.1 ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-08-22 20:27 Message: Logged In: YES user_id=671362 Same here :: ./Misc/cheatsheet: x+y x-y addition, substraction ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1266296&group_id=5470 From noreply at sourceforge.net Mon Aug 22 21:38:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 22 Aug 2005 12:38:40 -0700 Subject: [ python-Feature Requests-1260171 ] subprocess: more general (non-buffering) communication Message-ID: Feature Requests item #1260171, was opened at 2005-08-15 21:15 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1260171&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: None Status: Open Resolution: None Priority: 5 Submitted By: Ian Bicking (ianbicking) >Assigned to: Peter ?strand (astrand) Summary: subprocess: more general (non-buffering) communication Initial Comment: Right now you can use subprocess.Popen.communicate() to make communication with subprocesses much easier and less likely to block than communicating directly with .stdin, .stdout, etc. However, that requires completely buffering the input and output. The functionality of communicate() (which is somewhat complex because of platform issues) could be made more general fairly easily. The current functionality of communicate could then be implemented in terms of that new method. I attached a function I'm using which does that for the posix systems (basically turning Popen's posix communicate into a function with some modifications). Replace "proc" with "self" (and give the function a better name) and you'd have a method. If patch 1175984 was accepted, then this wouldn't be that much of an issue: http://sourceforge.net/tracker/index.php?func=detail&aid=1175984&group_id=5470&atid=305470 ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-22 21:38 Message: Logged In: YES user_id=1188172 Reclassifying as RFE. Assigning to Peter. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-08-22 21:03 Message: Logged In: YES user_id=341410 Also, what you post is not a 'bug', it is a 'feature request'. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-08-22 21:02 Message: Logged In: YES user_id=341410 Would an asynchronous subprocess (which you would poll manually) be better/sufficient? http://python.org/sf/1191964 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1260171&group_id=5470 From noreply at sourceforge.net Tue Aug 23 04:25:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 22 Aug 2005 19:25:52 -0700 Subject: [ python-Bugs-1265100 ] sequence slicing documentation incomplete Message-ID: Bugs item #1265100, was opened at 2005-08-20 15:30 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1265100&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: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: sequence slicing documentation incomplete Initial Comment: Here's what points (3) and (5) of the Sequence Types[1] documentation say now: """ (3) If i or j is negative, the index is relative to the end of the string: len(s) + i or len(s) + j is substituted. But note that -0 is still 0. ... (5) The slice of s from i to j with step k is defined as the sequence of items with index x = i + n*k such that $0 \leq n < \frac{j-i}{k}$. In other words, the indices are i, i+k, i+2*k, i+3*k and so on, stopping when j is reached (but never including j). If i or j is greater than len(s), use len(s). If i or j are omitted then they become ``end'' values (which end depends on the sign of k). Note, k cannot be zero. """ I'd like to replace that second-to-last sentence in point (5), which uses the vague word "end'' in its description, with something more explicit. I'd like it to read something like: """ If k is positive and i or j is omitted, they will be replaced with 0 and len(s) respectively. If k is negative and i or j is omitted, they will be replaced with -1 and -len(s)-1 respectively. Note that these replacements happen before the rule from point (3) is applied. """ I'd also like to put an example with point (5) to show this behavior in action. Something like: """ So for example:: >>> seq = 'abcde' >>> len(seq) 5 >>> 'edc' == seq[:1:-1] == seq[-1:1:-1] True >>> 'ca' == seq[2::-2] == seq[2:-5-1:-2] True Note however that manually applying the rule from point (3) (adding len(s) to any i or j that is negative) works for i, but does not work for j:: >>> seq[5-1:1:-1] 'edc' >>> seq[2:-1:-2] '' This is because Python sees the -1 in the j position and applies the rule from point (3) again. """ One of the motivations for this patch is to be able to explain the difference in behavior between sequence slicing and slice.indices(), e.g. >>> seq[::-2] 'eca' >>> slice(None, None, -2).indices(5) (4, -1, -2) >>> seq[4:-1:-2] '' Right now, I think the documentation is too vague to be able to make it clear why slices behave differently. If this patch is accepted, I'll work on a patch for slice objects that explains the differences. [1] http://docs.python.org/lib/typesseq.html ---------------------------------------------------------------------- >Comment By: Steven Bethard (bediviere) Date: 2005-08-22 20:25 Message: Logged In: YES user_id=945502 Sure, I'm not particular. If you can put some of this in the slice.indices(), that would be great too. I'd just like it (or something like it) to be somewhere, because there's currently no good place to reference for the differences between sequence slicing and slice.indices() behavior. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-21 03:29 Message: Logged In: YES user_id=80475 -0 The docs read better with "vague" words like "end". Making the description more mathematical may make it more precise but will also make it harder to just read and understand. The wording suggested above is fathomable only after you already understand how slicing works. It is the "vague" words that help achieve the understanding in the first place. Also, I do not want to clutter this section with examples intended to compare and contrast slices versus slice.indices. It would be okay to add a brief comparative example to the docs for slice.indices(). Understanding the latter is aided by a comparison. In contrast, you can get pretty good with slices and know nothing about slice.indices() which is a somewhat challenging method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1265100&group_id=5470 From noreply at sourceforge.net Tue Aug 23 04:48:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 22 Aug 2005 19:48:32 -0700 Subject: [ python-Bugs-1263656 ] IDLE on Mac Message-ID: Bugs item #1263656, was opened at 2005-08-18 22:35 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263656&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: IDLE Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bruce Sherwood (bsherwood) >Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE on Mac Initial Comment: Copying code from some browsers into IDLE on the Mac can leave the file with only \r (13) at the ends of lines (Safari doesn't seem to have this problem). Then checksyntax() in ScriptBinding.py fails to convert these into \n (10), and compile() fails. The effect is that a program which Python is willing to run gets a syntax error in IDLE. I think the fix is in checksyntax() to add after source = re.sub(r"\r\n", "\n", source) the following statement, which converts unaccompanied \r's into \n's:: source = re.sub(r"\r", "\n", source) I've tried this and it works, but someone with a better overview of end-of-line issues in Python should think through whether this is the appropriate fix. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-08-22 22:48 Message: Logged In: YES user_id=149084 ScriptBinding 1.62. Backport to 2.4.2 Seems harmless. Please check. IDLE retains line endings when loading code from a file. In this case OS X uses \r in the GUI and \r\n in the OS. Heaven knows what happens with fink/X11. IDLE expects \n internally, line endings are converted on I/O. What is your os.linesep under the conditions you mentioned? Regular expression pattern elements like r'\n' match the corresponding special characters; both bytes have to be in the pattern. You can do it by escaping the backslash in a regular string, '\n', which is also two bytes. But it's easier to use raw strings with regular expressions. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2005-08-19 12:16 Message: Logged In: YES user_id=34881 I should have said that this is in the environment of running IDLE on Mac OSX 10.4 under X11, using the fink distribution. I should also say that there seem to be issues not only of compiling but also of editing/display. In a browser, click on a .py file, select all the text, copy, paste into IDLE. With Safari, it looks right and it runs. With NetScape, it displays all on one line, and it doesn't run (syntax error). I haven't studied the actual code to see what if anything IDLE does to attempt to detect the nature of text pasted into an edit window, but clearly it's different coming from two popular browsers. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2005-08-19 00:23 Message: Logged In: YES user_id=34881 A footnote: Now I don't understand why the substitution searches for r"\r\n", since this would seem to be the raw string which represents slash, r, slash, n, not the two-character string "\r\n"....?? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263656&group_id=5470 From noreply at sourceforge.net Tue Aug 23 06:09:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 22 Aug 2005 21:09:11 -0700 Subject: [ python-Bugs-736659 ] markupbase parse_declaration cannot recognize comments Message-ID: Bugs item #736659, was opened at 2003-05-12 16:34 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736659&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: None >Status: Closed >Resolution: Wont Fix Priority: 4 Submitted By: Jim Jewett (jimjjewett) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: markupbase parse_declaration cannot recognize comments Initial Comment: In markupbase class parser method parse_declaration It verfies that the first two characters are "<!" Then it returns -1 if the next character is "-". After that, it checks to see if the next two characters are "--", but if they were, it would already have returned. Solution: Check for comments before checking for a short buffer. if rawdata[j:j+1] == '--': #comment # Locate --.*-- as the body of the comment return self.parse_comment(i) if rawdata[j:j+1] in ("-", ""): # Start of comment followed by buffer # boundary, or just a buffer boundary. return -1 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-08-23 00:09 Message: Logged In: YES user_id=3066 Closed by docstring change in Lib/markupbase.py revisions 1.11, 1.10.4.1. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-09-09 01:18 Message: Logged In: YES user_id=3066 As noted in the related patch (#901369), this probably shouldn't be considered a bug. Keeping this open pending outcome of email discussion with OP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736659&group_id=5470 From noreply at sourceforge.net Tue Aug 23 14:10:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 05:10:24 -0700 Subject: [ python-Bugs-1262856 ] fcntl.ioctl have a bit problem. Message-ID: Bugs item #1262856, was opened at 2005-08-18 09:53 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1262856&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: Raise L. Sail (fullsail) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl.ioctl have a bit problem. Initial Comment: First, I write python program on Linux. The function ioctl of fcntl module, take a integer parameter as ioctl command. in python 2.3.x, if this command value is more than 0x80000000, interpreter will popup some warnning message. but in python 2.4.x, it raise a exception directly. My solution is writing one cutoms module in C. but this is so ugly. There are some ioctl command value are more than 0x80000000, I think we should not reject "negative" ioctl command. enjoy. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-08-23 13:10 Message: Logged In: YES user_id=6656 I think this is fixed in CVS HEAD. Can you try that? As a workaround, you can probably pass ~int(~v&0xFFFFFFFF) to ioctl instead of v (which is very ugly, yes, but probably not as ugly as a C extension). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1262856&group_id=5470 From noreply at sourceforge.net Tue Aug 23 19:41:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 10:41:38 -0700 Subject: [ python-Bugs-1263656 ] IDLE on Mac Message-ID: Bugs item #1263656, was opened at 2005-08-18 22:35 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263656&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: IDLE Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE on Mac Initial Comment: Copying code from some browsers into IDLE on the Mac can leave the file with only \r (13) at the ends of lines (Safari doesn't seem to have this problem). Then checksyntax() in ScriptBinding.py fails to convert these into \n (10), and compile() fails. The effect is that a program which Python is willing to run gets a syntax error in IDLE. I think the fix is in checksyntax() to add after source = re.sub(r"\r\n", "\n", source) the following statement, which converts unaccompanied \r's into \n's:: source = re.sub(r"\r", "\n", source) I've tried this and it works, but someone with a better overview of end-of-line issues in Python should think through whether this is the appropriate fix. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-08-23 13:41 Message: Logged In: YES user_id=149084 Backported, ScriptBinding.py 1.28.4.1 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-08-22 22:48 Message: Logged In: YES user_id=149084 ScriptBinding 1.62. Backport to 2.4.2 Seems harmless. Please check. IDLE retains line endings when loading code from a file. In this case OS X uses \r in the GUI and \r\n in the OS. Heaven knows what happens with fink/X11. IDLE expects \n internally, line endings are converted on I/O. What is your os.linesep under the conditions you mentioned? Regular expression pattern elements like r'\n' match the corresponding special characters; both bytes have to be in the pattern. You can do it by escaping the backslash in a regular string, '\n', which is also two bytes. But it's easier to use raw strings with regular expressions. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2005-08-19 12:16 Message: Logged In: YES user_id=34881 I should have said that this is in the environment of running IDLE on Mac OSX 10.4 under X11, using the fink distribution. I should also say that there seem to be issues not only of compiling but also of editing/display. In a browser, click on a .py file, select all the text, copy, paste into IDLE. With Safari, it looks right and it runs. With NetScape, it displays all on one line, and it doesn't run (syntax error). I haven't studied the actual code to see what if anything IDLE does to attempt to detect the nature of text pasted into an edit window, but clearly it's different coming from two popular browsers. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2005-08-19 00:23 Message: Logged In: YES user_id=34881 A footnote: Now I don't understand why the substitution searches for r"\r\n", since this would seem to be the raw string which represents slash, r, slash, n, not the two-character string "\r\n"....?? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263656&group_id=5470 From noreply at sourceforge.net Tue Aug 23 20:02:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 11:02:52 -0700 Subject: [ python-Bugs-1108992 ] IDLE Freezes on Ubuntu Warty Message-ID: Bugs item #1108992, was opened at 2005-01-25 05:44 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&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: IDLE Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Mark Poolman (mgpoolman) >Assigned to: Kurt B. Kaiser (kbk) >Summary: IDLE Freezes on Ubuntu Warty Initial Comment: Python 2.3.4 (#2, Aug 13 2004, 00:36:58) [GCC 3.3.4 (Debian 1:3.3.4-5ubuntu2)] on linux2 IDLE 1.0.3 When running idle over an ssh link, idle freezes after an unpredictable length of time. Over 3 days the longest it has stayed allive for is ~4hrs, but a few minutes before freezing is the norm. Niether idle nor python are consuming cpu time once frozen. I can find no definete recipie to bring about the freeze, although (I think) there has always been at least one editor window open when it happens. There is no output on stderr, or other diagnostics that I can see. ssh server(ubuntu warty): OpenSSH_3.8.1p1 Debian 1:3.8.1p1-11ubuntu3.1, OpenSSL 0.9.7d 17 Mar 2004 ssh client (RH9): OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f /best/* Mark ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-08-23 14:02 Message: Logged In: YES user_id=149084 Closing as unreproducible. Exhibits only on Ubuntu Warty on a specific machine. ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-04-19 07:05 Message: Logged In: YES user_id=993923 Haven't been using the machine in question for a while. I can't reproduce the problem on an opteron with equivalent set up. (The machine I reported this on is a celeron). I've atatched a stack trace from gdb, having interrupted with ctrl-C at the gdb prompt when idle froze. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-04-14 17:01 Message: Logged In: YES user_id=149084 Any update on this? ---------------------------------------------------------------------- Comment By: SUZUKI Hisao (suzuki_hisao) Date: 2005-03-18 20:46 Message: Logged In: YES user_id=495142 If 1) your IDLE freezes when you close an editor window 2) which has been editing a file whose path contains a non-ASCII character, and 3) you do not call sys.setdefaultencoding() in your sitecustomize.py (so letting the default encoding to be 'ascii'), then my patch 'idlelib.diff' in Python Patch ID 1162825 "EditorWindow's title with non-ASCII chars." may help you. More precisely, IDLE freezes when updating the "Recent Files" menu if an implicit conversion of unicode to ASCII string occurs. The patch fixes it. Sorry if it is irrelevant. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-03-03 19:28 Message: Logged In: YES user_id=149084 There have been recent reports on idle-dev regarding IDLE freezing on Debian Sid. Since ubuntu is Debian derived, I assume there may be a relationship. ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-02-02 13:50 Message: Logged In: YES user_id=993923 >0.8 doesn't have the problem. Are you sure? Can't be certain as haven't used it for extended periods on that box, but I'll look into it. I've used IDLE daily for about 4 years on various RH and Suse, and never seen a problem until now. > What else is the ubuntu box doing? Is the load heavy? Almost nothing, it's there to evaluate ubuntu as a desktop w/s, and my main activity is getting some in-house python s/w ported to it. gdb results to follow. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-02 12:21 Message: Logged In: YES user_id=149084 To keep things simple, please start IDLE with the -n switch directly on your ubuntu box for the purposes of future investigations on this issue. Can you attach to the frozen IDLE with gdb and then use 'bt' to get a backtrace and find out what was going at at the time of the freeze? If so, is it repeatable? It's occasionally reported that IDLE freezes. I've never seen it myself, running IDLE for many days on OpenBSD, Debian, RH, and Arch Linux, WindowsXP, W2K, and W98, over a period of many years, so it's hard for me to figure out what's going on. But it's peculiar that 0.8 doesn't have the problem. Are you sure? What else is the ubuntu box doing? Is the load heavy? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-02-01 08:35 Message: Logged In: YES user_id=993923 > So if I follow correctly, IDLE -n freezes on your ubuntu box without using ssh tunneling. That is correct. The problem appears exactly the same when run over ssh though, which, I guess rules out any gnome/metacity/X wierdness. > I suspect a hardware problem I' sceptical about that. There's nothing in dmesg or /var/log to suggest it, and absolutely no other problems with the machine in question. >Are you starting IDLE from the command line Yes, but no messages are shown. > How much memory 255MB, IDLE uses about 3.5% of that on startup, grew to 5.7% at time of last crash ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-31 21:01 Message: Logged In: YES user_id=149084 Right, there is no subprocess when you use the -n switch. It causes IDLE to run like IDLE 0.8. So if I follow correctly, IDLE -n freezes on your ubuntu box without using ssh tunneling. I suspect a hardware problem with that system. Are you starting IDLE on the ubuntu box from the command line? If so, are there any messages left in the command line window? How much memory does the ubuntu box have? Does 'top' show increasing memory requirement for the IDLE -n process? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-31 11:46 Message: Logged In: YES user_id=993923 2 - erm forgive me for sounding stupid, but with the -n switch I see no sub-process, only the Idle process. It still freezes though, and killing it just kills it. ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-31 11:27 Message: Logged In: YES user_id=993923 1 - OK It's not ssh it's ubuntu. 2 - I'll try this with ububtu. ...And by frozen, I assume ... All Idle windows are unresponsive to screen and kbd events. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-31 01:26 Message: Logged In: YES user_id=149084 Please try two things: 1. Run IDLE directly on the ubuntu machine long enough to assure there is no problem standalone. 2. Run IDLE on the xclient but start it with the -n switch so it runs without the subprocess. When IDLE freezes, walk over to the server and kill the subprocess. It should restart itself. Is the system still frozen? And by frozen, I assume you mean all screen and keyboard events are unresponsive. ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 15:06 Message: Logged In: YES user_id=993923 Yes, I've used Idle on that (although only ~ 1 hour) and not seen the problem there. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-30 14:43 Message: Logged In: YES user_id=341410 Do you have physical access to the ubuntu warty machine, and if so, does Idle run very well locally on that machine, not X forwarded? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 12:02 Message: Logged In: YES user_id=993923 Yes, exactly. I'm pretty sure it's not an X/ssh/network problem, everything else works fine (including Idle 0.8). Mark ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 15:23 Message: Logged In: YES user_id=341410 It has been a while since I ran Idle, but I am curious as to what you mean by "run over ssh". Do you mean that you have an SSH tunnel to a remote machine, which forwards X-Windows sessions, and when running Idle over this, it locks up? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-26 04:15 Message: Logged In: YES user_id=993923 PS - You don't need an editor window open to get the freeze. M ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 From noreply at sourceforge.net Tue Aug 23 20:08:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 11:08:53 -0700 Subject: [ python-Bugs-1168135 ] Python 2.5a0 Tutorial errors and observations Message-ID: Bugs item #1168135, was opened at 2005-03-22 01:58 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168135&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.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael R Bax (mrbax) Assigned to: Raymond Hettinger (rhettinger) Summary: Python 2.5a0 Tutorial errors and observations Initial Comment: Please find attached my updated list of errors and observations in response to Python 2.5a0. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-23 13:08 Message: Logged In: YES user_id=80475 Applied many of the suggestions. ---------------------------------------------------------------------- Comment By: Michael R Bax (mrbax) Date: 2005-04-06 07:39 Message: Logged In: YES user_id=1055057 Thanks for your comments. A handful of meta-observations: Front Matter > Your first correction is wrong. -ly adverbs are never hyphenated > (Chicago Manual of Style, Table 6.1, for instance). "Wrong" is wrong. In fact, the CMS Q&A explicitly states that "it has long been the practice elsewhere -- among British writers, for example -- to hyphenate ly + participle/adjective compounds. ... So it is a matter not of who is right or wrong but of whose rule you are going to follow." But I'm happy to leave it as is, given that it is a regional preference. 3.1.2 > > >>> word[:1] = 'Splat' > > -- This is trying to assign 5 letters to one? > > Slice assignment is replacement, not overwriting. This is > replacing 1 byte with 5, which *is* valid, and perhaps the point > being made. Perhaps you would recommend another change to > be clearer? I'm not recommending a change per se; I'm showing what a newbie reader thinks! :-) 5.2 > > There is a way to remove an item from a list given its index > > instead of its value: the del statement. > > -- How is this different to pop? > > pop, builtin on top of del, also saves and returns the deleted value > so it can be bound to something, which takes longer. ie > def pop(self, i): > ret = self[i] > del self[i] > return ret Again, this is a question that the newbie reader will pose. I may know the answer, but I am not asking the question for myself. I think the question should be answered pre- emptively in the tutorial! 9.2 > > Otherwise, all variables found outside of the innermost scope > > are read-only. > > -- Explain what happens when you try to assign to a > > read-only variable? > > You create a new local of the same name and will not be able to > read the masked variable. Right -- again, this is for the benefit of the newbie. Let's put that in the tutorial! :-) ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-30 16:01 Message: Logged In: YES user_id=593130 Subject to reading that particular version (.5a0), I generally agree with your suggestions. Here are some specific comments on your comments. Feel free to incorporate them into a revised suggestion list if you wish. ----------- Your first correction is wrong. -ly adverbs are never hyphenated (Chicago Manual of Style, Table 6.1, for instance). ----------- 3.1.2 >>> word[:1] = 'Splat' -- This is trying to assign 5 letters to one? Slice assignment is replacement, not overwriting. This is replacing 1 byte with 5, which *is* valid, and perhaps the point being made. Perhaps you would recommend another change to be clearer? ----------- ##5.1.3 ##Combining these two special cases, we see that "map(None, list1, list2)" is a convenient way of turning a pair of lists into a list of pairs # -- Shouldn't one rather use zip()? I would agree that 'convenient' should be removed and a note added that this has been superceded by zip unless one wants the different behavior of extending shorter sequences. ---------- 5.1.3 filter(function, sequence)" returns a sequence (of the same type, if possible) -- How could this ever be impossible? I suppose a broken class, but then what would filter do? If filter 'works' for all builtins, I agree that we should just say so. Perhaps 'returns a sequence of the same type (for all builtins and sensible user classes)' -- if that is true -------- 5.2 There is a way to remove an item from a list given its index instead of its value: the del statement. -- How is this different to pop? pop, builtin on top of del, also saves and returns the deleted value so it can be bound to something, which takes longer. ie def pop(self, i): ret = self[i] del self[i] return ret ---------------------------- 5.3 Sequence unpacking requires that the list of variables on the left have the same number of elements as the length of the sequence -- requires that the list of variables on the left has (grammar) -- requires the list of variables on the left to have (alternate) Since the code sequence on the left is not a Python list but only a common-meaning list, I think even better would be "Sequence unpacking requires that the number of variables on the left be the same as the length of the sequence on the right" ------------------ 5.7 Comparisons may be combined by the Boolean operators and and or -- combined using the (style) In general, the return value of a short-circuit operator, when used as a general value and not as a Boolean, is the last evaluated argument. -- rewrite: When used as a general value and not as a Boolean, the return value of a short-circuit operator is the last evaluated argument. I would personally be a bit more radical here. As has been said often on c.l.p in response to newby misconceptions about 'and' and 'or', they are not operators, in the sense of syntactically abbreviating function calls, but flow-control keywords abbreviating if-else constructs. Saying so in the tutorial might 'short-circuit' some of the misconceptions. ------------- 9 a derived class can override any methods of its base class or classes, a method can call the method of a base class with the same name. -- classes, and a method (last phrase in a list) There are no special constructors or destructors. -- What about __init__, or is that a "normal" constructor? The special method __new__ constructs (and initializes immutables) (so why isn't it a 'special constructor'?), __init__ initializes, But as I remember, the quoted sentence does seem confusing. --------------- 9.2 Otherwise, all variables found outside of the innermost scope are read-only. -- Explain what happens when you try to assign to a read-only variable? You create a new local of the same name and will not be able to read the masked variable. ------------ 9.8 raise Class, instance -- What's the point? In the example thereafter, these three have the same effect: raise c() raise B, c() raise instance -- wasn't this "new form" covered in 8.5 (raise MyClass (2*2))? I personally agree that the tutorial should emphasize the newest form (raise instance) and only mention back-compatible forms in passing. ... - What is an example of an exception that is NOT a class? Last I knew, strings are still legal, though deprecated. ------------- 9.11 sum(i*i for i in range(10)) -- Why does this work?! because generator expressions require their own parentheses *unless* already directly enclosed by function-call parens. I agree that this nice quirk should be explained, ------------- B.1 ... >>> 7205759403792794L * 10L**30 / 2L**56 -- The "L" extension does not appear to be necessary for the input -- why is it used? Used to be needed before int-long unification. I agree that tutorial should be updated to future-oriented present. ---------- C The socket module uses the functions, getaddrinfo, and getnameinfo -- remove comma after "functions" [grammar] and after getaddrinfo ------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168135&group_id=5470 From noreply at sourceforge.net Wed Aug 24 01:29:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 16:29:05 -0700 Subject: [ python-Bugs-1267540 ] _register is not safe Message-ID: Bugs item #1267540, was opened at 2005-08-23 16:29 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=1267540&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: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: _register is not safe Initial Comment: The _register function is not safe. It uses the following code to generate a unique string to identify a python callable entity: f = CallWrapper(func, subst, self).__call__ name = repr(id(f)) It then adds the function name if func has a __name__ attribute, but bound methods don't have that, and it is bound methods that cause the problem because they don't have a constant id number unless somebody bothers to keep an explicit reference to the bound reference around (keeping a reference to the object itself isn't enough). For example: class foo: def meth1(self): pass def meth2(self): pass f = foo() print id(f) print id(f.meth1) print id(f.meth2) Odds are good that the last two printed numbers will be the same even though they are for two different bound methods. The id of f will persist and remain unique as long as the object exists, but the id of its bound methods will not. Even though one can call the bound methods as long as the object persists. I don't know how to best handle this. Possibilities include: - Use hash(func) instead of id(func). I don't know enough about the built in hash to know if that is safe. Certainly it is the right idea. One wants a function that has the same value if the callable entity is the same and a different value otherwise. - Generate a new hash function that is sure to work. "paolino" suggested the following hash function for bound methods (when I first asked about this problem on comp.lang.python): id(boundMethod.im_self)^id(boundMethod.im_func) this is probably the simplest solution if hash itself isn't safe, but it requires a some fiddling to figure out what kind of callable entity one has, and thus what hash equation is suitable. - Keep a reference to the callable entity, so its id number cannot be reused. That sounds hard to do safely; it would be all too easy to introduce a memory leak. It can probably be done fairly easily for the case cleanup=1, but there is code that uses cleanup=0 (including bind_all and bind_class). -- Russell ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267540&group_id=5470 From noreply at sourceforge.net Wed Aug 24 01:59:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 16:59:07 -0700 Subject: [ python-Bugs-1267547 ] bdist_rpm hardcodes setup.py as the script name Message-ID: Bugs item #1267547, was opened at 2005-08-23 23:59 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=1267547&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: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fernando P?rez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_rpm hardcodes setup.py as the script name Initial Comment: The bdist_rpm command hardcodes 'setup.py' as the name of the setup script in the .spec file it generates. A grep of the bdist_rpm file shows this: planck[command]> grep -n -C 3 setup.py bdist_rpm.py 454- 455- # rpm scripts 456- # figure out default build script 457: def_build = "%s setup.py build" % self.python 458- if self.use_rpm_opt_flags: 459- def_build = 'env CFLAGS="$RPM_OPT_FLAGS" ' + def_build 460- -- 468- ('prep', 'prep_script', "%setup"), 469- ('build', 'build_script', def_build), 470- ('install', 'install_script', 471: ("%s setup.py install " 472- "--root=$RPM_BUILD_ROOT " 473- "--record=INSTALLED_FILES") % self.python), 474- ('clean', 'clean_script', "rm -rf $RPM_BUILD_ROOT"), But there are packages out there which ship with multiple setup files, named setup-foo.py, setup-bar.py, etc. While distutils correctly copies over the proper setup-X.py file to the build/ directory, the bdist_rpm command fails because rpm then tries to issue a build command against 'setup.py', which doesn't exist. An example can be seen by downloading the clnum library from http://calcrpnpy.sourceforge.net/clnum.html, and trying: lanck[rpncalc-2.0]> python clnum_setup.py bdist_rpm running bdist_rpm creating build creating build/bdist.linux-i686 creating build/bdist.linux-i686/rpm creating build/bdist.linux-i686/rpm/SOURCES creating build/bdist.linux-i686/rpm/SPECS creating build/bdist.linux-i686/rpm/BUILD creating build/bdist.linux-i686/rpm/RPMS creating build/bdist.linux-i686/rpm/SRPMS writing 'build/bdist.linux-i686/rpm/SPECS/clnum.spec' running sdist warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list) warning: sdist: standard file not found: should have one of README, README.txt writing manifest file 'MANIFEST' creating clnum-1.0 creating clnum-1.0/clnum creating clnum-1.0/clnum/src creating clnum-1.0/test making hard links in clnum-1.0... hard linking clnum_setup.py -> clnum-1.0 hard linking clnum/__init__.py -> clnum-1.0/clnum hard linking clnum/_clnum_str.py -> clnum-1.0/clnum hard linking clnum/src/clnum.cpp -> clnum-1.0/clnum/src hard linking test/test_clnum.py -> clnum-1.0/test [... snip] Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.8191 + umask 022 + cd /usr/local/installers/src/rpncalc-2.0/build/bdist.linux-i686/rpm/BUILD + cd clnum-1.0 + LANG=C + export LANG + unset DISPLAY + env 'CFLAGS=-O2 -g -pipe -m32 -march=i386 -mtune=pentium4' python setup.py build python: can't open file 'setup.py' error: Bad exit status from /var/tmp/rpm-tmp.8191 (%build) I think that the fix is as simple as replacing the hardcoded 'setup.py' name by os.path.basename(sys.argv[0]), but I'm not 100% sure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267547&group_id=5470 From noreply at sourceforge.net Wed Aug 24 05:42:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 20:42:55 -0700 Subject: [ python-Bugs-1248119 ] pdb 'next' does not skip list comprehension Message-ID: Bugs item #1248119, was opened at 2005-07-30 14:12 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&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: Joseph Heled (pepster) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'next' does not skip list comprehension Initial Comment: pdb next command forces you to step over each list element. This seem to be a reincarnation of this old bug. https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523995&group_id=5470 Version: Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-08-23 20:42 Message: Logged In: YES user_id=971153 I raised this question on python-dev. There was only a couple of replies. To summarize: the original "next N" suggestion got -1 (b/c in gdb "next N" means repeat "next" N times and it is desirable to keep pdb's and gdb's command sets as close as possible), however the alternative suggestion to implement "until" (which is also supported by gdb) got +1. Python-dev reference: http://mail.python.org/pipermail/python-dev/2005-August/055298.html Patch #1267629 implements 'until' and should address the original problem. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-08-07 13:36 Message: Logged In: YES user_id=971153 > The only viable workaround now is to wrap the code in a > temporary function (i.e. lambda : ...). ugly. Would setting a temporary breakpoint (tbreak) on the line after list comprehension be a much simpler workaround? ---------------------------------------------------------------------- Comment By: Joseph Heled (pepster) Date: 2005-07-31 19:25 Message: Logged In: YES user_id=86677 I think this will be wonderfull .... The only viable workaround now is to wrap the code in a temporary function (i.e. lambda : ...). ugly. -Thanks, JOseph ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-31 13:48 Message: Logged In: YES user_id=971153 > you would realize what a serious bummer this is. I agree: this is a definite inconvenience. But I don't see how it is different from having to step through any other loop. However, I think there is a way to solve both problems at once..See below > Giving a 'next N' is nice, but will not be a real solution. > Somethims it is not easy to know how many iterations there > are. And when they are nested etc. Actually, I did not mean "next N" to skip N iterations, what I meant to have 'next N' (or at least next 1) to skip next N lines of code. I.e stop only when line>=line_where_next_N_happened+N is reached... So it seems like we are talking about the same thing...Right? There are a couple of corner cases which would have to be handled, (e.g keeping track of the current frame, etc) Also "next N" would allow to easily skip over any loops (not just list comprehensions), which I think would be a useful feature... What do you think? ---------------------------------------------------------------------- Comment By: Joseph Heled (pepster) Date: 2005-07-30 23:02 Message: Logged In: YES user_id=86677 You probably never use pdb in a real program, otherwise you would realize what a serious bummer this is. Giving a 'next N' is nice, but will not be a real solution. Somethims it is not easy to know how many iterations there are. And when they are nested etc. If you are convinced this is the desired and reasonable behaviour for next (a point of view I don't share), at least have a different command to skip to the next line. I am sorry but I have no idea if this is easy or hard. Thanks, Joseph ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 20:20 Message: Logged In: YES user_id=971153 While this behaviour indeed feels like a bug I'm starting to think that it is not.. Observation1: 'step' should stop at every iteration of a list comprehension Observation2: the only difference between 'step' and 'next' is that 'step' steps into function calls (which is not the case here) So, it seems like 'next' should also stop at every iteration of a list comprehenstion. Ie current behaviour is not a bug... Would supporting a numeric argument for the 'next' command make sense? So that 'next 1' would mean "stop when actual line number increases by at least 1"... ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 17:59 Message: Logged In: YES user_id=971153 A bit more information. I looked into what happens in ceval.c and apparently the current behaviour is intentional.. Looks like this piece of code: else if (frame->f_lasti <= *instr_prev) { /* jumping back in the same line forces a trace event */ result = call_trace(func, obj, frame, PyTrace_LINE, Py_None); } in maybe_call_line_trace() is responsible for the extra "line" events.. Seems like this piece of code was added to fix bug #765624. in ceval.c:2.386 So, should this (1248119) bug be dealt with by skipping extra line events in bdb? Any thoughts? Or am I totally lost? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 17:33 Message: Logged In: YES user_id=971153 I changed bdb.py to print the kind of event it receives as well as as line numbers and here is a session which illustrates the bug... bagira:~/python/dist/src/bug-next1248119> cat t #../python y=[1,2,3,4] x=[ i+1 for i in y] print x bagira:~/python/dist/src/bug-next1248119> ../python -m pdb t event: call; line 1, file event: line; line 1, file event: call; line 2, file t event: line; line 2, file t > /home/ilya/python/dist/src/bug-next1248119/t(2)?() -> y=[1,2,3,4] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] So it appears that the interpreter generates "line" events for every iteration of the loop.. Would this be a bug in the interpreter (and not in pdb/bdb)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&group_id=5470 From noreply at sourceforge.net Wed Aug 24 07:00:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 22:00:33 -0700 Subject: [ python-Bugs-1168983 ] ftplib.py string index out of range Message-ID: Bugs item #1168983, was opened at 2005-03-23 05:05 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168983&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: Accepted Priority: 5 Submitted By: David Carroll (vmlinuxz) Assigned to: Raymond Hettinger (rhettinger) Summary: ftplib.py string index out of range Initial Comment: The following code works great on all of the 2.3.x releases I have used. def ftpFetch(localPath,remoteFileDate,ftpSite,ftpPass,ftpDir,ftpUser): print "Fetching split_mgr report" fileList=[] processList=[] ftp = FTP(ftpSite) ftp.login(ftpUser,ftpPass) ftp.dir('LIST '+ftpDir,fileList.append) for x in range(len(fileList)): if (string.find(fileList[x],remoteFileDate) != -1): print fileList[x] TMP=fileList[x] output=localPath+str(TMP[45:]) print output processList.append(output) print processList outfile = open(output,'w') ftp.retrbinary('RETR '+ftpDir+TMP[45:], open(output, 'wb').write) ftp.quit() print processList return processList However I get the following error under 2.4 Traceback (most recent call last): File "C:\Python24\lib\site-packages\PythonCard\widget.py", line 417, in _dispatch handler(background, aWxEvent) File "C:\Documents and Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\readwaitreport.py", line 61, in on_btnRun_command mainRwclassLoop(self, mm+dd+yy, yesterday) File "C:\Documents and Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\rwclass.py", line 39, in mainRwclassLoop processList = ftpFetch(localPath,"split_mgr."+date[0:4],ftpSite,ftpPass,ftpDir,ftpUser) File "C:\Documents and Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\rwclass.py", line 173, in ftpFetch ftp.dir('LIST '+ftpDir,fileList.append) File "C:\Python24\lib\ftplib.py", line 464, in dir self.retrlines(cmd, func) File "C:\Python24\lib\ftplib.py", line 396, in retrlines conn = self.transfercmd(cmd) File "C:\Python24\lib\ftplib.py", line 345, in transfercmd return self.ntransfercmd(cmd, rest)[0] File "C:\Python24\lib\ftplib.py", line 328, in ntransfercmd if resp[0] != '1': IndexError: string index out of range https://lists.dulug.duke.edu/pipermail/yum/2004-August/005067.html discusses a similar problem under Linux in the YUM script, I have reproduced this error under 2000, and XP. I'm a fairly new programmer, and thus very new to python so I hope this is enough information. I will try and keep track of this and help out with more information in any capacity I can. Thank you for all your hard work and dedication. David Carroll ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 00:00 Message: Logged In: YES user_id=80475 If you're issue has been addressed, go ahead and close it. ---------------------------------------------------------------------- Comment By: David Carroll (vmlinuxz) Date: 2005-04-11 04:13 Message: Logged In: YES user_id=684143 I'm not sure if this needs any more clarification, but for accuracy I'm attaching a file with the working and non working code segments, and the level 2 debug. This code was run on 2.3, using your new ftplib modifications, and the distributed ftplib. The FTP server is wu-2.6.2(1) running on a SCO system (bleh). The code was tested in PASV and PORT mode. I'm new to this so I don't know if I should close this or the patch submitter. If you need anything else from me let me know. David ---------------------------------------------------------------------- Comment By: David Carroll (vmlinuxz) Date: 2005-04-08 05:13 Message: Logged In: YES user_id=684143 I achieve the same results with the following code. ftp = FTP('ftp.cdrom.com') ftp.login('anonymous', 'anonymous@') ftp.retrlines('LIST') This code works just fine with your patched ftplib.py, or the old ftplib.py against all public internet ftp servers I have tried it on. It works on the server at work only sporadically,, and raising the protocol exception the rest of the time. I'm inclined to think that there may be a problem with the protocol implementation on the server side. The server software version is wu-2.6.2(1), and the only oddity I see with it is a pretty sizeable delay before giving the login. Up to 10 seconds. I'd love to get a pointer of where to take this debugging process next. Perhaps I need to use a sniffer on the connection or something. I would love to see what ftplib.py is getting back that is breaking it. ---------------------------------------------------------------------- Comment By: David Carroll (vmlinuxz) Date: 2005-04-07 04:51 Message: Logged In: YES user_id=684143 Thank you for leaving this open. I will try and get your example today. I'm too uneducated to realize what I'm doing wrong, so maybe you can use my ignorance for the common good =). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-04 23:31 Message: Logged In: YES user_id=80475 I fixed the IndexError. It should have been a protocol error. See Lib/ftplib.py 1.74. Leaving the bug open so the OP can make a more detailed post so we can see what the root issue is about. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-04-04 22:37 Message: Logged In: YES user_id=971153 It turns out that the code in plain text bug report is more or less readable, so I can see what you were trying to do... Seems like you are doing ftp.dir("LIST "+ftpDir) But ftplib docs: http://www.python.org/doc/current/lib/ftp-objects.html say that you need to specify the directory ftp.dir(ftpDir) so it seems that you are using ftp.dir() incorrectly.... But, even then IndexError seems like a wrong kind of exception for this kind of error... So, I guess, my original request for a working code snippet which would allow to reproduce the bug still stands.. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-04-04 21:12 Message: Logged In: YES user_id=971153 Could you submit a minimalistic piece of code which illustrates the problem? As well as any input data which are required to reproduce it? (SourceForge garbled your original example) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168983&group_id=5470 From noreply at sourceforge.net Wed Aug 24 07:04:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 22:04:12 -0700 Subject: [ python-Bugs-1192315 ] 'clear -1' in pdb Message-ID: Bugs item #1192315, was opened at 2005-04-29 05:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192315&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: Accepted Priority: 5 Submitted By: Pechkin (mpech) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: 'clear -1' in pdb Initial Comment: Delete breakpoints like in %subj% is great feature, but wrong. Add additional check like in do_enable() if not (0 <= i < len(bdb.Breakpoint.bpbynumber)): ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 00:04 Message: Logged In: YES user_id=80475 For the print statement, I would have used something simpler: print 'No breakpoint numbered', i ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 05:11 Message: Logged In: YES user_id=1188172 Attached patch which implements the check. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192315&group_id=5470 From noreply at sourceforge.net Wed Aug 24 07:10:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 22:10:25 -0700 Subject: [ python-Bugs-1190204 ] 3.29 site is confusing re site-packages on Windows Message-ID: Bugs item #1190204, was opened at 2005-04-26 07:26 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190204&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: Accepted Priority: 5 Submitted By: Kent Johnson (kjohnson) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: 3.29 site is confusing re site-packages on Windows Initial Comment: Library Reference 3.29 site seems to say that site-packages is only searched on Unix and Mac. The relevant sentence is in the third paragraph: "For the tail part, it uses the empty string (on Windows) or it uses first lib/python2.4/site-packages and then lib/site-python (on Unixand Macintosh)." A clearer and more accurate wording would be "For the tail part, it uses the empty string and lib/site-python (on Windows) or it uses first lib/python2.4/site-packages and then lib/site-python (on Unixand Macintosh)." The relevant code is line 187 in site.py. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 00:10 Message: Logged In: YES user_id=80475 Before you check in doc changes, be sure to spellcheck and use: python -m texcheck libsite.tex ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 13:24 Message: Logged In: YES user_id=1188172 Fix attached; okay to checkin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190204&group_id=5470 From noreply at sourceforge.net Wed Aug 24 07:10:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 22:10:56 -0700 Subject: [ python-Bugs-1168983 ] ftplib.py string index out of range Message-ID: Bugs item #1168983, was opened at 2005-03-23 05:05 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168983&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: Accepted Priority: 5 Submitted By: David Carroll (vmlinuxz) >Assigned to: Nobody/Anonymous (nobody) Summary: ftplib.py string index out of range Initial Comment: The following code works great on all of the 2.3.x releases I have used. def ftpFetch(localPath,remoteFileDate,ftpSite,ftpPass,ftpDir,ftpUser): print "Fetching split_mgr report" fileList=[] processList=[] ftp = FTP(ftpSite) ftp.login(ftpUser,ftpPass) ftp.dir('LIST '+ftpDir,fileList.append) for x in range(len(fileList)): if (string.find(fileList[x],remoteFileDate) != -1): print fileList[x] TMP=fileList[x] output=localPath+str(TMP[45:]) print output processList.append(output) print processList outfile = open(output,'w') ftp.retrbinary('RETR '+ftpDir+TMP[45:], open(output, 'wb').write) ftp.quit() print processList return processList However I get the following error under 2.4 Traceback (most recent call last): File "C:\Python24\lib\site-packages\PythonCard\widget.py", line 417, in _dispatch handler(background, aWxEvent) File "C:\Documents and Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\readwaitreport.py", line 61, in on_btnRun_command mainRwclassLoop(self, mm+dd+yy, yesterday) File "C:\Documents and Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\rwclass.py", line 39, in mainRwclassLoop processList = ftpFetch(localPath,"split_mgr."+date[0:4],ftpSite,ftpPass,ftpDir,ftpUser) File "C:\Documents and Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\rwclass.py", line 173, in ftpFetch ftp.dir('LIST '+ftpDir,fileList.append) File "C:\Python24\lib\ftplib.py", line 464, in dir self.retrlines(cmd, func) File "C:\Python24\lib\ftplib.py", line 396, in retrlines conn = self.transfercmd(cmd) File "C:\Python24\lib\ftplib.py", line 345, in transfercmd return self.ntransfercmd(cmd, rest)[0] File "C:\Python24\lib\ftplib.py", line 328, in ntransfercmd if resp[0] != '1': IndexError: string index out of range https://lists.dulug.duke.edu/pipermail/yum/2004-August/005067.html discusses a similar problem under Linux in the YUM script, I have reproduced this error under 2000, and XP. I'm a fairly new programmer, and thus very new to python so I hope this is enough information. I will try and keep track of this and help out with more information in any capacity I can. Thank you for all your hard work and dedication. David Carroll ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 00:00 Message: Logged In: YES user_id=80475 If you're issue has been addressed, go ahead and close it. ---------------------------------------------------------------------- Comment By: David Carroll (vmlinuxz) Date: 2005-04-11 04:13 Message: Logged In: YES user_id=684143 I'm not sure if this needs any more clarification, but for accuracy I'm attaching a file with the working and non working code segments, and the level 2 debug. This code was run on 2.3, using your new ftplib modifications, and the distributed ftplib. The FTP server is wu-2.6.2(1) running on a SCO system (bleh). The code was tested in PASV and PORT mode. I'm new to this so I don't know if I should close this or the patch submitter. If you need anything else from me let me know. David ---------------------------------------------------------------------- Comment By: David Carroll (vmlinuxz) Date: 2005-04-08 05:13 Message: Logged In: YES user_id=684143 I achieve the same results with the following code. ftp = FTP('ftp.cdrom.com') ftp.login('anonymous', 'anonymous@') ftp.retrlines('LIST') This code works just fine with your patched ftplib.py, or the old ftplib.py against all public internet ftp servers I have tried it on. It works on the server at work only sporadically,, and raising the protocol exception the rest of the time. I'm inclined to think that there may be a problem with the protocol implementation on the server side. The server software version is wu-2.6.2(1), and the only oddity I see with it is a pretty sizeable delay before giving the login. Up to 10 seconds. I'd love to get a pointer of where to take this debugging process next. Perhaps I need to use a sniffer on the connection or something. I would love to see what ftplib.py is getting back that is breaking it. ---------------------------------------------------------------------- Comment By: David Carroll (vmlinuxz) Date: 2005-04-07 04:51 Message: Logged In: YES user_id=684143 Thank you for leaving this open. I will try and get your example today. I'm too uneducated to realize what I'm doing wrong, so maybe you can use my ignorance for the common good =). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-04 23:31 Message: Logged In: YES user_id=80475 I fixed the IndexError. It should have been a protocol error. See Lib/ftplib.py 1.74. Leaving the bug open so the OP can make a more detailed post so we can see what the root issue is about. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-04-04 22:37 Message: Logged In: YES user_id=971153 It turns out that the code in plain text bug report is more or less readable, so I can see what you were trying to do... Seems like you are doing ftp.dir("LIST "+ftpDir) But ftplib docs: http://www.python.org/doc/current/lib/ftp-objects.html say that you need to specify the directory ftp.dir(ftpDir) so it seems that you are using ftp.dir() incorrectly.... But, even then IndexError seems like a wrong kind of exception for this kind of error... So, I guess, my original request for a working code snippet which would allow to reproduce the bug still stands.. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-04-04 21:12 Message: Logged In: YES user_id=971153 Could you submit a minimalistic piece of code which illustrates the problem? As well as any input data which are required to reproduce it? (SourceForge garbled your original example) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168983&group_id=5470 From noreply at sourceforge.net Wed Aug 24 07:11:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 22:11:59 -0700 Subject: [ python-Bugs-1082487 ] font lock keyword regular expressions Message-ID: Bugs item #1082487, was opened at 2004-12-09 16:43 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&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: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Robert Brown (robert-brown) Assigned to: Raymond Hettinger (rhettinger) Summary: font lock keyword regular expressions Initial Comment: I've noticed that when I use Python mode (alpha 1) with font lock mode, "self" is highlighted in the following line: his_self() The problem appears to be a combination of using "\b" in the Python font lock regular expressions and my .emacs file, which does: (modify-syntax-entry ?\_ "_" py-mode-syntax-table) I do not experience similar problems with highlighting in C mode, but there "\<" and "\>" are used in the font lock regular expressions. Using these word delimiters instead of "\b" appears to fix the problem for me in Python mode. Please wrap keywords with "\<" and "\>" instead of with "\b" in the font lock regular expression. Thanks very much. Bob ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-05-22 20:41 Message: Logged In: YES user_id=44345 Passing along to Raymond. If it works for you, please close. If not, pass it back to me. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-05-19 21:45 Message: Logged In: YES user_id=44345 python-mode.el 4.71. Raymond, sorry for taking so long with this. Please give it a try and let me know how it works. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 22:36 Message: Logged In: YES user_id=80475 Skip, can you field this one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&group_id=5470 From noreply at sourceforge.net Wed Aug 24 07:16:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 22:16:16 -0700 Subject: [ python-Bugs-1193849 ] os.path.expanduser documentation wrt. empty $HOME Message-ID: Bugs item #1193849, was opened at 2005-05-02 10:02 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193849&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: Accepted Priority: 5 Submitted By: Wummel (calvin) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: os.path.expanduser documentation wrt. empty $HOME Initial Comment: If $HOME is unset, an initial "~" should not be expanded according to the documentation. But instead it somehow is expanded, perhaps through the pwd module: $ env -u HOME python -c "import os.path; print os.path.expanduser('~/foo')" /home/calvin/foo The result should be "~/foo" instead of "/home/calvin/foo". I suggest adjusting the documentation to state the also a single "~" is looked up in the pwd module, not only "~user". ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 00:16 Message: Logged In: YES user_id=80475 Strike the comma before the final "or". After you post this, put a note on your todo list to check its appearance in the HTML docs whenever Fred runs an update: http://www.python.org/dev/doc/devel/ ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 07:29 Message: Logged In: YES user_id=1188172 Attached a patch which fixes the docs. Okay to checkin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193849&group_id=5470 From noreply at sourceforge.net Wed Aug 24 07:18:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 22:18:09 -0700 Subject: [ python-Bugs-1007046 ] os.startfile() doesn't accept Unicode filenames Message-ID: Bugs item #1007046, was opened at 2004-08-11 01:47 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007046&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Huening (huening) >Assigned to: M.-A. Lemburg (lemburg) Summary: os.startfile() doesn't accept Unicode filenames Initial Comment: WinXP, Python 2.3.4 os.startfile() seems to have problems with Unicode filenames. Example: >>> import tkFileDialog >>> import os >>> f = tkFileDialog.askopenfilename() >>> type(f) >>> os.startfile(f) Traceback (most recent call last): File "", line 1, in -toplevel- os.startfile(f) UnicodeEncodeError: 'ascii' codec can't encode characters in position 14-16: ordinal not in range(128) >>> ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 00:18 Message: Logged In: YES user_id=80475 I'm unicode illiterate. Passing to MAL for review. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 16:24 Message: Logged In: YES user_id=1188172 Attaching a patch which should fix that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007046&group_id=5470 From noreply at sourceforge.net Wed Aug 24 07:24:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 22:24:23 -0700 Subject: [ python-Bugs-728515 ] mmap's resize method resizes the file in win32 but not unix Message-ID: Bugs item #728515, was opened at 2003-04-27 12:44 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&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: Accepted Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: mmap's resize method resizes the file in win32 but not unix Initial Comment: In the resize method under win32 you have something like this: /* Move to the desired EOF position */ SetFilePointer (self->file_handle, new_size, NULL, FILE_BEGIN); /* Change the size of the file */ SetEndOfFile (self->file_handle); Which resizes the file Under Unix you need to call ftruncate(self->fileno, new_size) before calling remap() to make it do the same thing. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 15:50 Message: Logged In: YES user_id=1188172 Attaching patch which duplicates the file handle under UNIX too (btw, the size() method was broken too), mimics Windows behaviour with resize(), adds a testcase for this and clarifies the docs. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 15:12 Message: Logged In: YES user_id=1188172 This is not trivial since the filehandle can be closed at the time the ftruncate() would be necessary. The Windows specific code duplicates the filehandle upon mmap creation, perhaps the UNIX code should do this too? Then, the ftruncate call can be inserted. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 18:51 Message: Logged In: YES user_id=752496 Reopened as posted that still is a bug. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-30 18:32 Message: Logged In: YES user_id=341410 The problem still persists in Python 2.3 and 2.4. A quick read of mmapmodule.c shows that ftruncate() is not being called within the non-windows portion of mmap_resize_method(). ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 13:59 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 12:55 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 07:36 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? Please make sure to include changes to the documentation and test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 From noreply at sourceforge.net Wed Aug 24 07:25:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 22:25:48 -0700 Subject: [ python-Bugs-718532 ] inspect, class instances and __getattr__ Message-ID: Bugs item #718532, was opened at 2003-04-09 15:01 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&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: 6 Submitted By: Stefan Schwarzer (sschwarzer) >Assigned to: Ka-Ping Yee (ping) Summary: inspect, class instances and __getattr__ Initial Comment: inspect.isclass(class_instance) fails if the corresponding class uses a "wildcard" implementation of __getattr__. Example: Python 2.2.2 (#1, Nov 13 2002, 22:53:57) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import inspect >>> class X: ... def __getattr__(self, name): ... if name == 'foo': ... return 1 ... if name == 'bar': ... return 2 ... else: ... return "default" ... >>> x = X() >>> inspect.isclass(x) 1 The problematic expression in inspect.isclass is hasattr(object, '__bases__') which returns a true value. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 00:25 Message: Logged In: YES user_id=80475 Ping, do you have a few minutes to look at this one and make sure its the right thing to do. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 14:15 Message: Logged In: YES user_id=752496 Don't know yet if it's a bug or not, but in Py2.4.1 inspect.isclass() is still returning True in these cases... ---------------------------------------------------------------------- Comment By: Stefan Schwarzer (sschwarzer) Date: 2005-01-28 11:44 Message: Logged In: YES user_id=383516 Hi Facundo The problem still exists in both Python 2.3.4 and 2.4. A possible test case is: import inspect import unittest class TestIsclass(unittest.TestCase): def test_instance_with_getattr(self): class Cls: def __getattr__(self, name): return "not important" obj = Cls() # obj is not a class self.failIf(inspect.isclass(obj)) ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 12:50 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-15 05:40 Message: Logged In: YES user_id=80475 Ping, if this change is made, will isclass() still be able to find extension classes? The addition of the hasattr(object, '__bases__') was made by you in ver 1.11 about two years ago. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-04-15 05:01 Message: Logged In: YES user_id=89016 type(object) in (types.TypeType, types.ClassType) won't work with custom metaclasses. isinstance(object, (type, types.ClassType)) would be better. ---------------------------------------------------------------------- Comment By: Stefan Schwarzer (sschwarzer) Date: 2003-04-15 03:01 Message: Logged In: YES user_id=383516 Hello Raymond, thanks for your reply. In fact, I'm also not sure if it counts as a bug. I also suggested a patch (handle __getattr__ requests for __bases__ with an AttributeError) for for the SF project which causes/d the problem. I think, if there's a better way to decide on "class-ness" than now, the code in inspect should be changed. Fortunately, it doesn't have to be backward-compatible, because the module is always distributed with a certain interpreter version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-14 19:36 Message: Logged In: YES user_id=80475 Hmm. I'm not sure that counts as a bug. In an OO language, it's a feature that objects can be made to look like and be substituable for other types. In this case, you've taught your object to be able to fake some classlike behavior (having a __bases__ attribute). OTOH, inspect could have a stronger test for classhood: type(object) in (types.TypeType, types.ClassType) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470 From noreply at sourceforge.net Wed Aug 24 07:34:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 22:34:43 -0700 Subject: [ python-Bugs-1267540 ] _register is not safe Message-ID: Bugs item #1267540, was opened at 2005-08-24 01:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267540&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: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: _register is not safe Initial Comment: The _register function is not safe. It uses the following code to generate a unique string to identify a python callable entity: f = CallWrapper(func, subst, self).__call__ name = repr(id(f)) It then adds the function name if func has a __name__ attribute, but bound methods don't have that, and it is bound methods that cause the problem because they don't have a constant id number unless somebody bothers to keep an explicit reference to the bound reference around (keeping a reference to the object itself isn't enough). For example: class foo: def meth1(self): pass def meth2(self): pass f = foo() print id(f) print id(f.meth1) print id(f.meth2) Odds are good that the last two printed numbers will be the same even though they are for two different bound methods. The id of f will persist and remain unique as long as the object exists, but the id of its bound methods will not. Even though one can call the bound methods as long as the object persists. I don't know how to best handle this. Possibilities include: - Use hash(func) instead of id(func). I don't know enough about the built in hash to know if that is safe. Certainly it is the right idea. One wants a function that has the same value if the callable entity is the same and a different value otherwise. - Generate a new hash function that is sure to work. "paolino" suggested the following hash function for bound methods (when I first asked about this problem on comp.lang.python): id(boundMethod.im_self)^id(boundMethod.im_func) this is probably the simplest solution if hash itself isn't safe, but it requires a some fiddling to figure out what kind of callable entity one has, and thus what hash equation is suitable. - Keep a reference to the callable entity, so its id number cannot be reused. That sounds hard to do safely; it would be all too easy to introduce a memory leak. It can probably be done fairly easily for the case cleanup=1, but there is code that uses cleanup=0 (including bind_all and bind_class). -- Russell ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-24 07:34 Message: Logged In: YES user_id=21627 Can you provide a test case that demonstrates the problem? I don't think there is anything wrong with that code. We don't take the id of func, we take the id of f, where f is CallWrapper(...).__call__. f gets then passed to tk.createcommand, which in turn puts f into PythonCmd_ClientData. So as long as the Tcl command lives, f (which is indeed a method) is referenced, which in turn means that no other method can have the same id. You are also wrong that the name is not added for bound methods. It looks at im_func, and then takes the name of the function in the bound method. >>> f.meth1.im_func.__name__ 'meth1' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267540&group_id=5470 From noreply at sourceforge.net Wed Aug 24 07:41:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 22:41:03 -0700 Subject: [ python-Bugs-1267547 ] bdist_rpm hardcodes setup.py as the script name Message-ID: Bugs item #1267547, was opened at 2005-08-24 01:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267547&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: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fernando P?rez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_rpm hardcodes setup.py as the script name Initial Comment: The bdist_rpm command hardcodes 'setup.py' as the name of the setup script in the .spec file it generates. A grep of the bdist_rpm file shows this: planck[command]> grep -n -C 3 setup.py bdist_rpm.py 454- 455- # rpm scripts 456- # figure out default build script 457: def_build = "%s setup.py build" % self.python 458- if self.use_rpm_opt_flags: 459- def_build = 'env CFLAGS="$RPM_OPT_FLAGS" ' + def_build 460- -- 468- ('prep', 'prep_script', "%setup"), 469- ('build', 'build_script', def_build), 470- ('install', 'install_script', 471: ("%s setup.py install " 472- "--root=$RPM_BUILD_ROOT " 473- "--record=INSTALLED_FILES") % self.python), 474- ('clean', 'clean_script', "rm -rf $RPM_BUILD_ROOT"), But there are packages out there which ship with multiple setup files, named setup-foo.py, setup-bar.py, etc. While distutils correctly copies over the proper setup-X.py file to the build/ directory, the bdist_rpm command fails because rpm then tries to issue a build command against 'setup.py', which doesn't exist. An example can be seen by downloading the clnum library from http://calcrpnpy.sourceforge.net/clnum.html, and trying: lanck[rpncalc-2.0]> python clnum_setup.py bdist_rpm running bdist_rpm creating build creating build/bdist.linux-i686 creating build/bdist.linux-i686/rpm creating build/bdist.linux-i686/rpm/SOURCES creating build/bdist.linux-i686/rpm/SPECS creating build/bdist.linux-i686/rpm/BUILD creating build/bdist.linux-i686/rpm/RPMS creating build/bdist.linux-i686/rpm/SRPMS writing 'build/bdist.linux-i686/rpm/SPECS/clnum.spec' running sdist warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list) warning: sdist: standard file not found: should have one of README, README.txt writing manifest file 'MANIFEST' creating clnum-1.0 creating clnum-1.0/clnum creating clnum-1.0/clnum/src creating clnum-1.0/test making hard links in clnum-1.0... hard linking clnum_setup.py -> clnum-1.0 hard linking clnum/__init__.py -> clnum-1.0/clnum hard linking clnum/_clnum_str.py -> clnum-1.0/clnum hard linking clnum/src/clnum.cpp -> clnum-1.0/clnum/src hard linking test/test_clnum.py -> clnum-1.0/test [... snip] Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.8191 + umask 022 + cd /usr/local/installers/src/rpncalc-2.0/build/bdist.linux-i686/rpm/BUILD + cd clnum-1.0 + LANG=C + export LANG + unset DISPLAY + env 'CFLAGS=-O2 -g -pipe -m32 -march=i386 -mtune=pentium4' python setup.py build python: can't open file 'setup.py' error: Bad exit status from /var/tmp/rpm-tmp.8191 (%build) I think that the fix is as simple as replacing the hardcoded 'setup.py' name by os.path.basename(sys.argv[0]), but I'm not 100% sure. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-24 07:41 Message: Logged In: YES user_id=21627 Would you like to try your proposed fix yourself, and contribute a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267547&group_id=5470 From noreply at sourceforge.net Wed Aug 24 08:08:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Aug 2005 23:08:32 -0700 Subject: [ python-Bugs-1257255 ] tarfile local name is local, should be abspath Message-ID: Bugs item #1257255, was opened at 2005-08-12 04:26 Message generated for change (Comment added) made by loewis 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: Closed >Resolution: Fixed 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. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-24 08:08 Message: Logged In: YES user_id=21627 This was fixed with said patch. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-08-17 14:34 Message: Logged In: YES user_id=642936 Thank you very much for your report. I added patch #1262036 that ought to fix the problem. ---------------------------------------------------------------------- Comment By: Martin Blais (blais) Date: 2005-08-15 19:34 Message: Logged In: YES user_id=10996 Oops, that was silly. My apologies. Here goes the file... ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-08-15 13:39 Message: Logged In: YES user_id=642936 Could you please attach the test code you mentioned? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257255&group_id=5470 From noreply at sourceforge.net Wed Aug 24 09:08:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 00:08:02 -0700 Subject: [ python-Bugs-1100368 ] Wrong "type()" syntax in docs Message-ID: Bugs item #1100368, was opened at 2005-01-11 14:03 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100368&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Facundo Batista (facundobatista) Assigned to: Raymond Hettinger (rhettinger) Summary: Wrong "type()" syntax in docs Initial Comment: >From the current docs: type(object): Return the type of an object. The return value is a type object. >From the interpreter: >>> help(type) Help on class type in module __builtin__: class type(object) | type(object) -> the object's type | type(name, bases, dict) -> a new type In the documentation is missing the second syntax form. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2005-08-13 18:32 Message: Logged In: YES user_id=945502 I was going to file this as a new bug report, but I changed my mind and decided to post it as a followup to this bug instead. It's basically a first draft at some documentation for the behavior of the type type. ---------- The type object documentation is limited and hard to find. The call type(obj) is defined in http://docs.python.org/lib/built-in-funcs.html and the call type(name, bases, dict) is briefly mentioned in http://docs.python.org/ref/metaclasses.html. Confusingly, the section on Type Objects (http://www.python.org/dev/doc/devel/lib/bltin-type-objects.html) is not about the type object at all; it's about *instances* of type, e.g. int or str. I'd like to add a section on the type object itself, something like: """ type(name, bases, dict) Return a new type object. This is essentially a functional form of the class statement: the "name" string is the class name and becomes the __name__ attribute, the "bases" tuple is the class bases and becomes the __bases__ attribute, the "dict" dict is the namespace defined by the class body, and becomes the __dict__ attribute. For example, the following two statements create identical "type" objects: >>> class X(object): ... a = 1 ... >>> X = type('X', (object,), dict(a=1)) Just like type objects created by class statements, type objects created by type() are callable, and when called create new instances of their type. The __call__() method of type objects accepts any number of positional and keyword arguments, and passes these to the type object's __new__() method to create a new instance. If __new__() returns an instance of the same type, that instance's __init__() method is then called with the same arguments. In either case, the __call__() method then returns the new instance. """ I don't know where this should go, but I'd certainly like to see something like this put in, and linked under the type() function, the Type Objects section and the Customizing class creation (metaclasses) section. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-01-25 16:31 Message: Logged In: YES user_id=99874 cjwhrh's comment doesn't seem relevent. It is generally true of ALL builtins that they can be shadowed by local variables. Facundo is probably right that the newer use of type() should be documented. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-01-18 17:03 Message: Logged In: YES user_id=285587 The accuracy of the above depends partly on the context. Within a function or method which has "type" as a parameter the type function described above is no longer accessible. Colin W. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100368&group_id=5470 From noreply at sourceforge.net Wed Aug 24 09:19:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 00:19:14 -0700 Subject: [ python-Bugs-728515 ] mmap's resize method resizes the file in win32 but not unix Message-ID: Bugs item #728515, was opened at 2003-04-27 19:44 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: mmap's resize method resizes the file in win32 but not unix Initial Comment: In the resize method under win32 you have something like this: /* Move to the desired EOF position */ SetFilePointer (self->file_handle, new_size, NULL, FILE_BEGIN); /* Change the size of the file */ SetEndOfFile (self->file_handle); Which resizes the file Under Unix you need to call ftruncate(self->fileno, new_size) before calling remap() to make it do the same thing. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-24 09:19 Message: Logged In: YES user_id=1188172 Okay, committed as Modules/mmapmodule.c; 2.50; 2.48.4.1 Lib/test/test_mmap.py; 1.33; 1.30.18.1 Doc/lib/libmmap.tex; 1.12; 1.9.4.2 ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 22:50 Message: Logged In: YES user_id=1188172 Attaching patch which duplicates the file handle under UNIX too (btw, the size() method was broken too), mimics Windows behaviour with resize(), adds a testcase for this and clarifies the docs. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 22:12 Message: Logged In: YES user_id=1188172 This is not trivial since the filehandle can be closed at the time the ftruncate() would be necessary. The Windows specific code duplicates the filehandle upon mmap creation, perhaps the UNIX code should do this too? Then, the ftruncate call can be inserted. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-31 01:51 Message: Logged In: YES user_id=752496 Reopened as posted that still is a bug. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 01:32 Message: Logged In: YES user_id=341410 The problem still persists in Python 2.3 and 2.4. A quick read of mmapmodule.c shows that ftruncate() is not being called within the non-windows portion of mmap_resize_method(). ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 20:59 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 18:55 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 14:36 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? Please make sure to include changes to the documentation and test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 From noreply at sourceforge.net Wed Aug 24 09:28:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 00:28:00 -0700 Subject: [ python-Bugs-1193849 ] os.path.expanduser documentation wrt. empty $HOME Message-ID: Bugs item #1193849, was opened at 2005-05-02 17:02 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193849&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Wummel (calvin) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: os.path.expanduser documentation wrt. empty $HOME Initial Comment: If $HOME is unset, an initial "~" should not be expanded according to the documentation. But instead it somehow is expanded, perhaps through the pwd module: $ env -u HOME python -c "import os.path; print os.path.expanduser('~/foo')" /home/calvin/foo The result should be "~/foo" instead of "/home/calvin/foo". I suggest adjusting the documentation to state the also a single "~" is looked up in the pwd module, not only "~user". ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-24 09:28 Message: Logged In: YES user_id=1188172 Okay, committed as Doc/lib/libposixpath.py 1.42, 1.40.2.2. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 07:16 Message: Logged In: YES user_id=80475 Strike the comma before the final "or". After you post this, put a note on your todo list to check its appearance in the HTML docs whenever Fred runs an update: http://www.python.org/dev/doc/devel/ ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 14:29 Message: Logged In: YES user_id=1188172 Attached a patch which fixes the docs. Okay to checkin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193849&group_id=5470 From noreply at sourceforge.net Wed Aug 24 09:32:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 00:32:29 -0700 Subject: [ python-Bugs-1190204 ] 3.29 site is confusing re site-packages on Windows Message-ID: Bugs item #1190204, was opened at 2005-04-26 14:26 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190204&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: 3.29 site is confusing re site-packages on Windows Initial Comment: Library Reference 3.29 site seems to say that site-packages is only searched on Unix and Mac. The relevant sentence is in the third paragraph: "For the tail part, it uses the empty string (on Windows) or it uses first lib/python2.4/site-packages and then lib/site-python (on Unixand Macintosh)." A clearer and more accurate wording would be "For the tail part, it uses the empty string and lib/site-python (on Windows) or it uses first lib/python2.4/site-packages and then lib/site-python (on Unixand Macintosh)." The relevant code is line 187 in site.py. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-24 09:32 Message: Logged In: YES user_id=1188172 Okay, committed as Doc/lib/libsite.tex 1.28, 1.26.4.2. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 07:10 Message: Logged In: YES user_id=80475 Before you check in doc changes, be sure to spellcheck and use: python -m texcheck libsite.tex ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 20:24 Message: Logged In: YES user_id=1188172 Fix attached; okay to checkin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190204&group_id=5470 From noreply at sourceforge.net Wed Aug 24 09:39:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 00:39:00 -0700 Subject: [ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1 Message-ID: Bugs item #1178484, was opened at 2005-04-07 14:33 Message generated for change (Comment added) 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: Martin v. L?wis (loewis) Date: 2005-08-24 09:39 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as libcodecs.tex 1.36 codecs.py 1.47 NEWS 1.1345 Checking in Doc/lib/libcodecs.tex; /cvsroot/python/python/dist/src/Doc/lib/libcodecs.tex,v <-- libcodecs.tex new revision: 1.34.2.2; previous revision: 1.34.2.1 done Checking in Lib/codecs.py; /cvsroot/python/python/dist/src/Lib/codecs.py,v <-- codecs.py new revision: 1.35.2.9; previous revision: 1.35.2.8 done Checking in Misc/NEWS; /cvsroot/python/python/dist/src/Misc/NEWS,v <-- NEWS new revision: 1.1193.2.81; previous revision: 1.1193.2.80 done ---------------------------------------------------------------------- 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 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 patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-18 11:31 Message: Logged In: YES user_id=38388 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. E.g. an ascii codec or latin-1 codec will only ever see standard line ends (not Unicode ones), so the streams .readline() method can be used directly - just like we did before the buffering code was added. 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. 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 ?! About your patch: * Please explain what firstline is supposed to do (preferably in the doc-string). * Why is firstline always set in .readline() ? * Please remove the print repr() * You cannot always be sure that exc has a .start attribute, so you need to accomocate for this situation as well ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-17 18:50 Message: Logged In: YES user_id=89016 It isn't the buffering support per se that breaks the tokenizer. This problem exists even in Python 2.3.x (Simply try the test scripts from http://www.python.org/sf/1089395 with Python 2.3.5 and you'll get a segfault). Applications that rely on len(readline(x)) == x or anything similar are broken anyway. Supporting buffered and unbuffered reading would mean keeping the 2.3 mode of doing things around indefinitely, and we'd loose readline() support for UTF-16 again. BTW, applying Greg Chapman's patch (http://www.python.org/sf/1101726, which fixes the tokenizer) together with this one seems to fix the problem from my previous post. So if you could give http://www.python.org/sf/1101726 a third look, so we can get it into 2.4.2, this would be great. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-17 11:13 Message: Logged In: YES user_id=38388 Walter, I think that instead of trying to get the tokenizer to work with the buffer support in the codecs, you should add a flag that allows to switch off the buffer support in the codecs altogether and then use the unbuffered mode codecs in the tokenizer. I expect that other applications will run into the same kind of problem, so it should be possible to switch off buffering if needed (maybe we should make this the default ?!). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 10:35 Message: Logged In: YES user_id=89016 OK, here is a patch. It adds an additional argument firstline to read(). If this argument is true (i.e. if called from readline()) and a decoding error happens, this error will only be reported if it is in the first line. Otherwise read() will decode up to the error position and put the rest in the bytebuffer. Unfortunately with this patch, I get a segfault with the following stacktrace if I run the test. I don't know if this is related to bug #1089395/patch #1101726. Martin, can you take a look? #0 0x08057ad1 in tok_nextc (tok=0x81ca7b0) at tokenizer.c:719 #1 0x08058558 in tok_get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1075 #2 0x08059331 in PyTokenizer_Get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1466 #3 0x080561b1 in parsetok (tok=0x81ca7b0, g=0x8167980, start=257, err_ret=0xbffff440, flags=0) at parsetok.c:125 #4 0x0805613c in PyParser_ParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", g=0x8167980, start=257, ps1=0x0, ps2=0x0, err_ret=0xbffff440, flags=0) at parsetok.c:90 #5 0x080f3926 in PyParser_SimpleParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, flags=0) at pythonrun.c:1345 #6 0x080f352b in PyRun_FileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, globals=0xb7d62e94, locals=0xb7d62e94, closeit=1, flags=0xbffff544) at pythonrun.c:1239 #7 0x080f22f2 in PyRun_SimpleFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:860 #8 0x080f1b16 in PyRun_AnyFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:664 #9 0x08055e45 in Py_Main (argc=2, argv=0xbffff5f4) at main.c:484 #10 0x08055366 in main (argc=2, argv=0xbffff5f4) at python.c:23 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-07 16:28 Message: Logged In: YES user_id=89016 The reason for this is the new codec buffering code in 2.4: The codec might read and decode more data from the byte stream than is neccessary for decoding one line. I.e. when reading line n, the codec might decode bytes that belong to line n+1, n+2 etc. too. If there's a decoding error in this data, line n gets reported. I don't think there's a simple fix for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 From noreply at sourceforge.net Wed Aug 24 09:39:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 00:39:30 -0700 Subject: [ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1 Message-ID: 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: Closed 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: Martin v. L?wis (loewis) Date: 2005-08-24 09:39 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as libcodecs.tex 1.36 codecs.py 1.47 NEWS 1.1345 Checking in Doc/lib/libcodecs.tex; /cvsroot/python/python/dist/src/Doc/lib/libcodecs.tex,v <-- libcodecs.tex new revision: 1.34.2.2; previous revision: 1.34.2.1 done Checking in Lib/codecs.py; /cvsroot/python/python/dist/src/Lib/codecs.py,v <-- codecs.py new revision: 1.35.2.9; previous revision: 1.35.2.8 done Checking in Misc/NEWS; /cvsroot/python/python/dist/src/Misc/NEWS,v <-- NEWS new revision: 1.1193.2.81; previous revision: 1.1193.2.80 done ---------------------------------------------------------------------- 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 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 patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-18 11:31 Message: Logged In: YES user_id=38388 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. E.g. an ascii codec or latin-1 codec will only ever see standard line ends (not Unicode ones), so the streams .readline() method can be used directly - just like we did before the buffering code was added. 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. 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 ?! About your patch: * Please explain what firstline is supposed to do (preferably in the doc-string). * Why is firstline always set in .readline() ? * Please remove the print repr() * You cannot always be sure that exc has a .start attribute, so you need to accomocate for this situation as well ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-17 18:50 Message: Logged In: YES user_id=89016 It isn't the buffering support per se that breaks the tokenizer. This problem exists even in Python 2.3.x (Simply try the test scripts from http://www.python.org/sf/1089395 with Python 2.3.5 and you'll get a segfault). Applications that rely on len(readline(x)) == x or anything similar are broken anyway. Supporting buffered and unbuffered reading would mean keeping the 2.3 mode of doing things around indefinitely, and we'd loose readline() support for UTF-16 again. BTW, applying Greg Chapman's patch (http://www.python.org/sf/1101726, which fixes the tokenizer) together with this one seems to fix the problem from my previous post. So if you could give http://www.python.org/sf/1101726 a third look, so we can get it into 2.4.2, this would be great. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-17 11:13 Message: Logged In: YES user_id=38388 Walter, I think that instead of trying to get the tokenizer to work with the buffer support in the codecs, you should add a flag that allows to switch off the buffer support in the codecs altogether and then use the unbuffered mode codecs in the tokenizer. I expect that other applications will run into the same kind of problem, so it should be possible to switch off buffering if needed (maybe we should make this the default ?!). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 10:35 Message: Logged In: YES user_id=89016 OK, here is a patch. It adds an additional argument firstline to read(). If this argument is true (i.e. if called from readline()) and a decoding error happens, this error will only be reported if it is in the first line. Otherwise read() will decode up to the error position and put the rest in the bytebuffer. Unfortunately with this patch, I get a segfault with the following stacktrace if I run the test. I don't know if this is related to bug #1089395/patch #1101726. Martin, can you take a look? #0 0x08057ad1 in tok_nextc (tok=0x81ca7b0) at tokenizer.c:719 #1 0x08058558 in tok_get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1075 #2 0x08059331 in PyTokenizer_Get (tok=0x81ca7b0, p_start=0xbffff3d4, p_end=0xbffff3d0) at tokenizer.c:1466 #3 0x080561b1 in parsetok (tok=0x81ca7b0, g=0x8167980, start=257, err_ret=0xbffff440, flags=0) at parsetok.c:125 #4 0x0805613c in PyParser_ParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", g=0x8167980, start=257, ps1=0x0, ps2=0x0, err_ret=0xbffff440, flags=0) at parsetok.c:90 #5 0x080f3926 in PyParser_SimpleParseFileFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, flags=0) at pythonrun.c:1345 #6 0x080f352b in PyRun_FileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", start=257, globals=0xb7d62e94, locals=0xb7d62e94, closeit=1, flags=0xbffff544) at pythonrun.c:1239 #7 0x080f22f2 in PyRun_SimpleFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:860 #8 0x080f1b16 in PyRun_AnyFileExFlags (fp=0x816bdb8, filename=0xbffff7b7 "./bug.py", closeit=1, flags=0xbffff544) at pythonrun.c:664 #9 0x08055e45 in Py_Main (argc=2, argv=0xbffff5f4) at main.c:484 #10 0x08055366 in main (argc=2, argv=0xbffff5f4) at python.c:23 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-07 16:28 Message: Logged In: YES user_id=89016 The reason for this is the new codec buffering code in 2.4: The codec might read and decode more data from the byte stream than is neccessary for decoding one line. I.e. when reading line n, the codec might decode bytes that belong to line n+1, n+2 etc. too. If there's a decoding error in this data, line n gets reported. I don't think there's a simple fix for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 From noreply at sourceforge.net Wed Aug 24 09:45:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 00:45:07 -0700 Subject: [ python-Bugs-1251631 ] Python 2.4.1 crashes when importing the attached script Message-ID: Bugs item #1251631, was opened at 2005-08-04 09:18 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251631&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: None >Priority: 7 Submitted By: Viktor Ferenczi (complex) Assigned to: Martin v. L?wis (loewis) Summary: Python 2.4.1 crashes when importing the attached script Initial Comment: OS: WinXP Prog. ENG SP1 Python: 2.4.1 MSI installer downloaded from python.org Python crashes or rarely raises MemoryError or SyntaxError when trying to import/execute the script attached. The behaviour changes when some lines are modified, but mostly crashes the python process with a memory access violation. The python process used 4.2Mbytes of system memory when crashed. There were more than 500Mbytes free. Register dump: EAX = 00A8CC61 EBX = 0000000A ECX = 00000000 EDX = 00000000 ESI = 00A10DA0 EDI = 00000022 EIP = 1E0A7F10 ESP = 0021FD98 EBP = 00000222 EFlags = 00000293 Other registers are irrelevant. The bug occured at the last line of the following instruction sequence because ECX was zero: 1E0A7EB2 66 C7 02 0A 00 mov word ptr [edx],0Ah 1E0A7EB7 8B 46 08 mov eax,dword ptr [esi+8] 1E0A7EBA 6A 00 push 0 1E0A7EBC 50 push eax 1E0A7EBD FF 15 B4 31 0C 1E call dword ptr ds:[1E0C31B4h] 1E0A7EC3 89 46 08 mov dword ptr [esi+8],eax 1E0A7EC6 8A 48 FF mov cl,byte ptr [eax-1] 1E0A7EC9 83 C4 08 add esp,8 1E0A7ECC 80 F9 0A cmp cl,0Ah 1E0A7ECF 0F 85 72 FF FF FF jne 1E0A7E47 1E0A7ED5 BB 0A 00 00 00 mov ebx,0Ah 1E0A7EDA 8B 0E mov ecx,dword ptr [esi] 1E0A7EDC 8B 54 24 0C mov edx,dword ptr [esp+0Ch] 1E0A7EE0 8D 04 11 lea eax,[ecx+edx] 1E0A7EE3 89 46 04 mov dword ptr [esi+4],eax 1E0A7EE6 8B 46 08 mov eax,dword ptr [esi+8] 1E0A7EE9 83 E8 02 sub eax,2 1E0A7EEC 3B C1 cmp eax,ecx 1E0A7EEE 72 0F jb 1E0A7EFF 1E0A7EF0 80 38 0D cmp byte ptr [eax],0Dh 1E0A7EF3 75 0A jne 1E0A7EFF 1E0A7EF5 C6 00 0A mov byte ptr [eax],0Ah 1E0A7EF8 40 inc eax 1E0A7EF9 C6 00 00 mov byte ptr [eax],0 1E0A7EFC 89 46 08 mov dword ptr [esi+8],eax 1E0A7EFF 39 5E 14 cmp dword ptr [esi+14h],ebx 1E0A7F02 75 21 jne 1E0A7F25 1E0A7F04 8B 4E 04 mov ecx,dword ptr [esi+4] 1E0A7F07 3B 4E 08 cmp ecx,dword ptr [esi+8] 1E0A7F0A 0F 84 24 FD FF FF je 1E0A7C34 1E0A7F10 0F B6 01 movzx eax,byte ptr [ecx] It may be possible to find the source line related to this bug by searching for this code in the retail python.exe then looking up the address in the map file produced by the compiler (if enabled). I can run the script with a debug version of python.exe. Please send me information about how to download a debug version for Windows. Note: I've tried to search this bug in the bug database, but it's not specific enough to find an exact match. No viruses nor spyware found on my machine using multiple antivirus/antispyware product. No memory errors found in 6 hours. I use LF (UNIX type) line ends on Windows to prevent errors when my scripts copied and edited on a Linux box. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-08 09:17 Message: Logged In: YES user_id=89016 The line number problem might be related to http://www.python.org/sf/1178484 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-08-07 19:40 Message: Logged In: YES user_id=31435 Note that it's not legal input: there's a non-ASCII character in line 225, which conflicts with the explicit # -*- coding: ascii -*-" directive near the top of file. Get rid of the non-ASCII character, and it seems to load fine. Current Python HEAD (2.4.2 development) gives a different outcome: File "pycrash.py", line 222 SyntaxError: unknown decode error That's peculiar too, because the offending character is actually on line 225, and because "unknown decode error" is unhelpful. Python 2.3 at least got the line number right: File "pycrash.py", line 225 SyntaxError: unknown decode error The best error report is gotten by deleting the encoding directive instead (using 2.4.1 here): sys:1: DeprecationWarning: Non-ASCII character '\xc1' in file pycrash.py on line 224, but no encoding declared; see http ://www.python.org/peps/pep-0263.html for details Assigning to Martin under the vague recollection that he knows most about the encoding implementation. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-08-04 09:21 Message: Logged In: YES user_id=142612 The bug could be in python.dll, of course. I need a debug version of python.dll. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251631&group_id=5470 From noreply at sourceforge.net Wed Aug 24 11:03:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 02:03:43 -0700 Subject: [ python-Feature Requests-1185121 ] itertools.imerge: merge sequences Message-ID: Feature Requests item #1185121, was opened at 2005-04-18 14:11 Message generated for change (Comment added) made by schoepflin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1185121&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: None Status: Closed Resolution: None Priority: 5 Submitted By: Jurjen N.E. Bos (jneb) Assigned to: Raymond Hettinger (rhettinger) Summary: itertools.imerge: merge sequences Initial Comment: (For the itertools library, so Python 2.2 and up) This is a suggested addition to itertools, proposed name imerge. usage: imerge(seq0, seq1, ..., [key=]) result: imerge assumes the sequences are all in sorted order, and produces a iterator that returns pairs of the form (value, index), where value is a value of one of the sequences, and index is the index number of the given sequence. The output the imerge is in sorted order (taking into account the key function), so that identical values in the sequences will be produced from left to right. The code is surprisingly short, making use of the builtin heap module. (You may disagree with my style of argument handling; feel free to optimize it.) def imerge(*iterlist, **key): """Merge a sequence of sorted iterables. Returns pairs [value, index] where each value comes from iterlist[index], and the pairs are sorted if each of the iterators is sorted. Hint use groupby(imerge(...), operator.itemgetter(0)) to get the items one by one. """ if key.keys() not in ([], ["key"]): raise TypeError, "Excess keyword arguments for imerge" key = key.get("key", lambda x:x) from heapq import heapreplace, heappop #initialize the heap containing (inited, value, index, currentItem, iterator) #this automatically makes sure all iterators are initialized, then run, and finally emptied heap = [(False, None, index, None, iter(iterator)) for index, iterator in enumerate(iterlist)] while heap: inited, item, index, value, iterator = heap[0] if inited: yield value, index try: item = iterator.next() except StopIteration: heappop(heap) else: heapreplace(heap, (True, key(item), index, item, iterator)) If you find this little routine worth its size, please put it into itertools. - Jurjen ---------------------------------------------------------------------- Comment By: Markus Sch?pflin (schoepflin) Date: 2005-08-24 11:03 Message: Logged In: YES user_id=91733 I was looking for exactly this functionality in itertools, so I would think it a good addition to the module. I have an application, which exposes messages in (possibly huge) log files via an iterator interface, and imerge allowed me to easily put together a little utility that merges log files from different sources according to the timestamp of the message. Markus ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-19 20:58 Message: Logged In: YES user_id=80475 For your specific application, it is better to use sorted(). When the underlying data consists of long runs of previously ordered data, sorted() will take advantage of that ordering and run in O(n) time. In contrast, using a heap will unnecessarily introduce O(n log n) behavior and not exploit the underlying data order. Recommend that you close this request. This discussion thus far confirms the original conclusion that imerge() use cases are dominated by sorted(chain(*iterlist)) which gives code that is shorter, faster, and easier to understand. ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2005-04-19 10:19 Message: Logged In: YES user_id=446428 Well, I was optimizing a piece of code with reasonbly long sorted lists (in memory, I agree) that were modified in all kinds of ways. I did not want the nlogn behaviour of sort, so I started writing a merge routine. I found out that the boundary cases of a merge implementation are a mess, until I disccovered the heap trick. Then I decided to clean it up and and put it up for a library routine. The fact that it uses iterators is obnly to make it more general, not specifically for the "lazy" properties. - Jurjen ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-19 00:43 Message: Logged In: YES user_id=80475 I had previously looked at an imerge() utility and found that it had only a single application (isomorphic to lazy mergesorting) and that the use cases were dominated by the in-memory alternative: sorted(chain(*iterlist)). Short of writing an external mergesort, what applications did you have in mind? What situations have you encountered where you have multiple sources of sorted data being generated on the fly (as opposed to already being in-memory), have needed one element at a time sequential access to a combined sort of that data, needed that combined sort only once, and could not afford to have the dataset in-memory? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1185121&group_id=5470 From noreply at sourceforge.net Wed Aug 24 11:04:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 02:04:12 -0700 Subject: [ python-Bugs-1192315 ] 'clear -1' in pdb Message-ID: Bugs item #1192315, was opened at 2005-04-29 12:30 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192315&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Pechkin (mpech) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: 'clear -1' in pdb Initial Comment: Delete breakpoints like in %subj% is great feature, but wrong. Add additional check like in do_enable() if not (0 <= i < len(bdb.Breakpoint.bpbynumber)): ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-24 11:04 Message: Logged In: YES user_id=1188172 Okay, committed as Lib/pdb.py 1.74, 1.73.2.1. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 07:04 Message: Logged In: YES user_id=80475 For the print statement, I would have used something simpler: print 'No breakpoint numbered', i ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 12:11 Message: Logged In: YES user_id=1188172 Attached patch which implements the check. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192315&group_id=5470 From noreply at sourceforge.net Wed Aug 24 12:22:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 03:22:05 -0700 Subject: [ python-Bugs-1267884 ] crash recursive __getattr__ Message-ID: Bugs item #1267884, was opened at 2005-08-24 12: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=1267884&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: pinzo (rodrigo_rc) Assigned to: Nobody/Anonymous (nobody) Summary: crash recursive __getattr__ Initial Comment: The following code eats all stack space and crashes, both in Windows and Linux: ------------8<------------- class C: def __getattr__(self, a): return object.__getattribute__(self, a) c = C() str(c) ------------8<------------- It shoud probably raise "RuntimeError: maximum recursion depth exceeded" or similar instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267884&group_id=5470 From noreply at sourceforge.net Wed Aug 24 16:08:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 07:08:23 -0700 Subject: [ python-Bugs-1168983 ] ftplib.py string index out of range Message-ID: Bugs item #1168983, was opened at 2005-03-23 10:05 Message generated for change (Settings changed) made by vmlinuxz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168983&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: Closed Resolution: Accepted Priority: 5 Submitted By: David Carroll (vmlinuxz) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib.py string index out of range Initial Comment: The following code works great on all of the 2.3.x releases I have used. def ftpFetch(localPath,remoteFileDate,ftpSite,ftpPass,ftpDir,ftpUser): print "Fetching split_mgr report" fileList=[] processList=[] ftp = FTP(ftpSite) ftp.login(ftpUser,ftpPass) ftp.dir('LIST '+ftpDir,fileList.append) for x in range(len(fileList)): if (string.find(fileList[x],remoteFileDate) != -1): print fileList[x] TMP=fileList[x] output=localPath+str(TMP[45:]) print output processList.append(output) print processList outfile = open(output,'w') ftp.retrbinary('RETR '+ftpDir+TMP[45:], open(output, 'wb').write) ftp.quit() print processList return processList However I get the following error under 2.4 Traceback (most recent call last): File "C:\Python24\lib\site-packages\PythonCard\widget.py", line 417, in _dispatch handler(background, aWxEvent) File "C:\Documents and Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\readwaitreport.py", line 61, in on_btnRun_command mainRwclassLoop(self, mm+dd+yy, yesterday) File "C:\Documents and Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\rwclass.py", line 39, in mainRwclassLoop processList = ftpFetch(localPath,"split_mgr."+date[0:4],ftpSite,ftpPass,ftpDir,ftpUser) File "C:\Documents and Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\rwclass.py", line 173, in ftpFetch ftp.dir('LIST '+ftpDir,fileList.append) File "C:\Python24\lib\ftplib.py", line 464, in dir self.retrlines(cmd, func) File "C:\Python24\lib\ftplib.py", line 396, in retrlines conn = self.transfercmd(cmd) File "C:\Python24\lib\ftplib.py", line 345, in transfercmd return self.ntransfercmd(cmd, rest)[0] File "C:\Python24\lib\ftplib.py", line 328, in ntransfercmd if resp[0] != '1': IndexError: string index out of range https://lists.dulug.duke.edu/pipermail/yum/2004-August/005067.html discusses a similar problem under Linux in the YUM script, I have reproduced this error under 2000, and XP. I'm a fairly new programmer, and thus very new to python so I hope this is enough information. I will try and keep track of this and help out with more information in any capacity I can. Thank you for all your hard work and dedication. David Carroll ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 05:00 Message: Logged In: YES user_id=80475 If you're issue has been addressed, go ahead and close it. ---------------------------------------------------------------------- Comment By: David Carroll (vmlinuxz) Date: 2005-04-11 09:13 Message: Logged In: YES user_id=684143 I'm not sure if this needs any more clarification, but for accuracy I'm attaching a file with the working and non working code segments, and the level 2 debug. This code was run on 2.3, using your new ftplib modifications, and the distributed ftplib. The FTP server is wu-2.6.2(1) running on a SCO system (bleh). The code was tested in PASV and PORT mode. I'm new to this so I don't know if I should close this or the patch submitter. If you need anything else from me let me know. David ---------------------------------------------------------------------- Comment By: David Carroll (vmlinuxz) Date: 2005-04-08 10:13 Message: Logged In: YES user_id=684143 I achieve the same results with the following code. ftp = FTP('ftp.cdrom.com') ftp.login('anonymous', 'anonymous@') ftp.retrlines('LIST') This code works just fine with your patched ftplib.py, or the old ftplib.py against all public internet ftp servers I have tried it on. It works on the server at work only sporadically,, and raising the protocol exception the rest of the time. I'm inclined to think that there may be a problem with the protocol implementation on the server side. The server software version is wu-2.6.2(1), and the only oddity I see with it is a pretty sizeable delay before giving the login. Up to 10 seconds. I'd love to get a pointer of where to take this debugging process next. Perhaps I need to use a sniffer on the connection or something. I would love to see what ftplib.py is getting back that is breaking it. ---------------------------------------------------------------------- Comment By: David Carroll (vmlinuxz) Date: 2005-04-07 09:51 Message: Logged In: YES user_id=684143 Thank you for leaving this open. I will try and get your example today. I'm too uneducated to realize what I'm doing wrong, so maybe you can use my ignorance for the common good =). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-05 04:31 Message: Logged In: YES user_id=80475 I fixed the IndexError. It should have been a protocol error. See Lib/ftplib.py 1.74. Leaving the bug open so the OP can make a more detailed post so we can see what the root issue is about. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-04-05 03:37 Message: Logged In: YES user_id=971153 It turns out that the code in plain text bug report is more or less readable, so I can see what you were trying to do... Seems like you are doing ftp.dir("LIST "+ftpDir) But ftplib docs: http://www.python.org/doc/current/lib/ftp-objects.html say that you need to specify the directory ftp.dir(ftpDir) so it seems that you are using ftp.dir() incorrectly.... But, even then IndexError seems like a wrong kind of exception for this kind of error... So, I guess, my original request for a working code snippet which would allow to reproduce the bug still stands.. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-04-05 02:12 Message: Logged In: YES user_id=971153 Could you submit a minimalistic piece of code which illustrates the problem? As well as any input data which are required to reproduce it? (SourceForge garbled your original example) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168983&group_id=5470 From noreply at sourceforge.net Wed Aug 24 16:56:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 07:56:24 -0700 Subject: [ python-Bugs-1121494 ] distutils.dir_utils not unicode compatible Message-ID: Bugs item #1121494, was opened at 2005-02-12 21:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121494&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: Distutils Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Morten Lied Johansen (epcylon) Assigned to: Nobody/Anonymous (nobody) Summary: distutils.dir_utils not unicode compatible Initial Comment: When sourcefiles are passed in as unicodestrings, distutils.dir_utils. mkpath will throw a DistutilsInternalError, as shown in the example attached. Using: Python 2.4 (#1, Feb 12 2005, 20:12:07) 2.6.9-gentoo-r9 GNU/Linux ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-24 16:56 Message: Logged In: YES user_id=21627 Fixed with said patch. ---------------------------------------------------------------------- Comment By: John M. Camara (camarajm) Date: 2005-03-21 18:01 Message: Logged In: YES user_id=1242541 patch 1167716 submitted ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121494&group_id=5470 From noreply at sourceforge.net Wed Aug 24 17:24:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 08:24:17 -0700 Subject: [ python-Feature Requests-567972 ] Missing 4 socket object properties Message-ID: Feature Requests item #567972, was opened at 2002-06-12 13:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&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: None Status: Open Resolution: None >Priority: 5 Submitted By: Graham Horler (grahamh) >Assigned to: Nobody/Anonymous (nobody) Summary: Missing 4 socket object properties Initial Comment: The C socketmodule has a struct PySocketSockObject, with family, type and proto members. These would be terribly helpful to have access to in Python, when implementing some generic socket helper functions. The "blocking" flag could also be made available, but would require some extra coding. (I'm using Python 2.1.3 under Linux 2.4.16, so I cannot extend the socket class itself ((as in py2.2)), and don't want to slow down sockets with a complete wrapper, as I use them heavily.) Thanks, Graham. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-24 17:24 Message: Logged In: YES user_id=21627 grahamh, I take it that your answer to the question "would you like to implement a patch?", is "no". I agree with parts of the review: these things should be added to the _socketobject. Also, socket objects have one more attribute, sock_timeout, which might be worth exposing. I also wonder what style of API should be used. All other state access goes through get-methods(), which all start with get except for fileno(). Adding properties would introduce another API style, so -1. As for blocking: this sounds like a different feature request, as this is not a member of struct PySocketSockObject. So I would close this request as soon as the three attributes are implemented; if you then still want the getblocking() method, you should write another feature request. In addition, this patch lacks documentation and test suite changes. Unassigning myself, as I won't take any further action for the moment. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2005-07-20 16:47 Message: Logged In: YES user_id=543663 The patch applies, compiles, runs OK for me (thanks). However it does not add access to the blocking flag. Under Linux I can go: fcntl.fcntl(fd, fcntl.F_GETFL) & os.O_NDELAY != 0 But this is not portable, and is probably repeating code. Also the 3 added members are not available from an instance of the _socketobject wrapper, you have to go mysock._sock.family. (The _socketobject wrapper in socket.py is a little bizarre IMVHO.) Perhaps they could be added using instances of property(). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 15:49 Message: Logged In: YES user_id=1188172 Attaching a patch which implements the three members of _socket.socket. Please review. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-06-15 15:21 Message: Logged In: YES user_id=21627 Sounds good. Would you like to produce a patch implementing this feature? ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-06-12 14:00 Message: Logged In: YES user_id=543663 Oh yes, the repr of a socket object includes the missing info, so to get hold of the family, I go: int(repr(sock).split(' ')[3].split('=')[1][:-1]) Similar for type and protocol, not nice! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470 From noreply at sourceforge.net Wed Aug 24 17:43:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 08:43:10 -0700 Subject: [ python-Bugs-1268519 ] email.MIMEText & email.MIMEMultipart "From" in message body Message-ID: Bugs item #1268519, was opened at 2005-08-24 15:43 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=1268519&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: Jim Kutter (jkutter) Assigned to: Nobody/Anonymous (nobody) Summary: email.MIMEText & email.MIMEMultipart "From" in message body Initial Comment: If a message contains a line starting with the word >From it will get prepended with a ">" character. Example (using 2.4.1 on Linux, also occurs in 2.3.5) attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1268519&group_id=5470 From noreply at sourceforge.net Wed Aug 24 17:55:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 08:55:28 -0700 Subject: [ python-Bugs-1268519 ] email.MIMEText & email.MIMEMultipart "From" in message body Message-ID: Bugs item #1268519, was opened at 2005-08-24 15:43 Message generated for change (Comment added) made by jkutter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1268519&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: Closed >Resolution: Invalid Priority: 5 Submitted By: Jim Kutter (jkutter) Assigned to: Nobody/Anonymous (nobody) Summary: email.MIMEText & email.MIMEMultipart "From" in message body Initial Comment: If a message contains a line starting with the word >From it will get prepended with a ">" character. Example (using 2.4.1 on Linux, also occurs in 2.3.5) attached. ---------------------------------------------------------------------- >Comment By: Jim Kutter (jkutter) Date: 2005-08-24 15:55 Message: Logged In: YES user_id=949682 Nevermind. Just figured out that is intended. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1268519&group_id=5470 From noreply at sourceforge.net Wed Aug 24 19:12:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 10:12:28 -0700 Subject: [ python-Bugs-1267547 ] bdist_rpm hardcodes setup.py as the script name Message-ID: Bugs item #1267547, was opened at 2005-08-23 23:59 Message generated for change (Comment added) made by fer_perez You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267547&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: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fernando P?rez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_rpm hardcodes setup.py as the script name Initial Comment: The bdist_rpm command hardcodes 'setup.py' as the name of the setup script in the .spec file it generates. A grep of the bdist_rpm file shows this: planck[command]> grep -n -C 3 setup.py bdist_rpm.py 454- 455- # rpm scripts 456- # figure out default build script 457: def_build = "%s setup.py build" % self.python 458- if self.use_rpm_opt_flags: 459- def_build = 'env CFLAGS="$RPM_OPT_FLAGS" ' + def_build 460- -- 468- ('prep', 'prep_script', "%setup"), 469- ('build', 'build_script', def_build), 470- ('install', 'install_script', 471: ("%s setup.py install " 472- "--root=$RPM_BUILD_ROOT " 473- "--record=INSTALLED_FILES") % self.python), 474- ('clean', 'clean_script', "rm -rf $RPM_BUILD_ROOT"), But there are packages out there which ship with multiple setup files, named setup-foo.py, setup-bar.py, etc. While distutils correctly copies over the proper setup-X.py file to the build/ directory, the bdist_rpm command fails because rpm then tries to issue a build command against 'setup.py', which doesn't exist. An example can be seen by downloading the clnum library from http://calcrpnpy.sourceforge.net/clnum.html, and trying: lanck[rpncalc-2.0]> python clnum_setup.py bdist_rpm running bdist_rpm creating build creating build/bdist.linux-i686 creating build/bdist.linux-i686/rpm creating build/bdist.linux-i686/rpm/SOURCES creating build/bdist.linux-i686/rpm/SPECS creating build/bdist.linux-i686/rpm/BUILD creating build/bdist.linux-i686/rpm/RPMS creating build/bdist.linux-i686/rpm/SRPMS writing 'build/bdist.linux-i686/rpm/SPECS/clnum.spec' running sdist warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list) warning: sdist: standard file not found: should have one of README, README.txt writing manifest file 'MANIFEST' creating clnum-1.0 creating clnum-1.0/clnum creating clnum-1.0/clnum/src creating clnum-1.0/test making hard links in clnum-1.0... hard linking clnum_setup.py -> clnum-1.0 hard linking clnum/__init__.py -> clnum-1.0/clnum hard linking clnum/_clnum_str.py -> clnum-1.0/clnum hard linking clnum/src/clnum.cpp -> clnum-1.0/clnum/src hard linking test/test_clnum.py -> clnum-1.0/test [... snip] Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.8191 + umask 022 + cd /usr/local/installers/src/rpncalc-2.0/build/bdist.linux-i686/rpm/BUILD + cd clnum-1.0 + LANG=C + export LANG + unset DISPLAY + env 'CFLAGS=-O2 -g -pipe -m32 -march=i386 -mtune=pentium4' python setup.py build python: can't open file 'setup.py' error: Bad exit status from /var/tmp/rpm-tmp.8191 (%build) I think that the fix is as simple as replacing the hardcoded 'setup.py' name by os.path.basename(sys.argv[0]), but I'm not 100% sure. ---------------------------------------------------------------------- >Comment By: Fernando P?rez (fer_perez) Date: 2005-08-24 17:12 Message: Logged In: YES user_id=395388 Well, here's a patch against 2.4 (sorry, but I can't build from CVS right now, I hope this is enough. I tested it on my problem build linked above, and it now works correctly, but I'm not a distutils expert, so I can't vouch 100% that it won't break in some corner case. It would be worth making sure that other similar commands (like the new bdist_deb in CVS) don't share the problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-24 05:41 Message: Logged In: YES user_id=21627 Would you like to try your proposed fix yourself, and contribute a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267547&group_id=5470 From noreply at sourceforge.net Wed Aug 24 19:40:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 10:40:41 -0700 Subject: [ python-Bugs-1267547 ] bdist_rpm hardcodes setup.py as the script name Message-ID: Bugs item #1267547, was opened at 2005-08-24 01:59 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267547&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: Distutils Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Fernando P?rez (fer_perez) >Assigned to: Martin v. L?wis (loewis) Summary: bdist_rpm hardcodes setup.py as the script name Initial Comment: The bdist_rpm command hardcodes 'setup.py' as the name of the setup script in the .spec file it generates. A grep of the bdist_rpm file shows this: planck[command]> grep -n -C 3 setup.py bdist_rpm.py 454- 455- # rpm scripts 456- # figure out default build script 457: def_build = "%s setup.py build" % self.python 458- if self.use_rpm_opt_flags: 459- def_build = 'env CFLAGS="$RPM_OPT_FLAGS" ' + def_build 460- -- 468- ('prep', 'prep_script', "%setup"), 469- ('build', 'build_script', def_build), 470- ('install', 'install_script', 471: ("%s setup.py install " 472- "--root=$RPM_BUILD_ROOT " 473- "--record=INSTALLED_FILES") % self.python), 474- ('clean', 'clean_script', "rm -rf $RPM_BUILD_ROOT"), But there are packages out there which ship with multiple setup files, named setup-foo.py, setup-bar.py, etc. While distutils correctly copies over the proper setup-X.py file to the build/ directory, the bdist_rpm command fails because rpm then tries to issue a build command against 'setup.py', which doesn't exist. An example can be seen by downloading the clnum library from http://calcrpnpy.sourceforge.net/clnum.html, and trying: lanck[rpncalc-2.0]> python clnum_setup.py bdist_rpm running bdist_rpm creating build creating build/bdist.linux-i686 creating build/bdist.linux-i686/rpm creating build/bdist.linux-i686/rpm/SOURCES creating build/bdist.linux-i686/rpm/SPECS creating build/bdist.linux-i686/rpm/BUILD creating build/bdist.linux-i686/rpm/RPMS creating build/bdist.linux-i686/rpm/SRPMS writing 'build/bdist.linux-i686/rpm/SPECS/clnum.spec' running sdist warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list) warning: sdist: standard file not found: should have one of README, README.txt writing manifest file 'MANIFEST' creating clnum-1.0 creating clnum-1.0/clnum creating clnum-1.0/clnum/src creating clnum-1.0/test making hard links in clnum-1.0... hard linking clnum_setup.py -> clnum-1.0 hard linking clnum/__init__.py -> clnum-1.0/clnum hard linking clnum/_clnum_str.py -> clnum-1.0/clnum hard linking clnum/src/clnum.cpp -> clnum-1.0/clnum/src hard linking test/test_clnum.py -> clnum-1.0/test [... snip] Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.8191 + umask 022 + cd /usr/local/installers/src/rpncalc-2.0/build/bdist.linux-i686/rpm/BUILD + cd clnum-1.0 + LANG=C + export LANG + unset DISPLAY + env 'CFLAGS=-O2 -g -pipe -m32 -march=i386 -mtune=pentium4' python setup.py build python: can't open file 'setup.py' error: Bad exit status from /var/tmp/rpm-tmp.8191 (%build) I think that the fix is as simple as replacing the hardcoded 'setup.py' name by os.path.basename(sys.argv[0]), but I'm not 100% sure. ---------------------------------------------------------------------- Comment By: Fernando P?rez (fer_perez) Date: 2005-08-24 19:12 Message: Logged In: YES user_id=395388 Well, here's a patch against 2.4 (sorry, but I can't build from CVS right now, I hope this is enough. I tested it on my problem build linked above, and it now works correctly, but I'm not a distutils expert, so I can't vouch 100% that it won't break in some corner case. It would be worth making sure that other similar commands (like the new bdist_deb in CVS) don't share the problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-24 07:41 Message: Logged In: YES user_id=21627 Would you like to try your proposed fix yourself, and contribute a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267547&group_id=5470 From noreply at sourceforge.net Wed Aug 24 20:49:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 11:49:21 -0700 Subject: [ python-Bugs-1016880 ] urllib.urlretrieve silently truncates downloads Message-ID: Bugs item #1016880, was opened at 2004-08-26 15:58 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016880&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: None >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: David Abrahams (david_abrahams) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: urllib.urlretrieve silently truncates downloads Initial Comment: The following script appears to be unreliable on all versions of Python we can find. The file being downloaded is approximately 34 MB. Browsers such as IE and Mozilla have no problem downloading the whole thing. ---- import urllib import os os.chdir('/tmp') urllib.urlretrieve ('http://cvs.sourceforge.net/cvstarballs/boost- cvsroot.tar.bz2', 'boost-cvsroot.tar.bz2') ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-24 20:49 Message: Logged In: YES user_id=1188172 Fixed wrt patch #1062060. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-12-24 15:30 Message: Logged In: YES user_id=129426 Suggested addition to the doc of urllib (liburllib.tex, if I'm not mistaken): """ urlretrieve will raise IOError when it detects that the amount of data available was less than the expected amount (which is the size reported by a Content-Length header). This can occur, for example, when the download is interrupted. The Content-Length is treated as a lower bound (just like tools such as wget and Ffirefox appear to do): if there's more data to read, urlretrieve reads more data, but if less data is available, it raises IOError. If no Content-Length header was supplied, urlretrieve can not check the size of the data it has downloaded, and just returns it. In this case you just have to assume that the download was successful. """ ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-11-07 21:17 Message: Logged In: YES user_id=129426 a patch is at 1062060 (raises IOError when download is incomplete) ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-11-07 20:47 Message: Logged In: YES user_id=129426 Confirmed here (mandrakelinux 10.0, python 2.4b2) However, I doubt it is a problem in urllib.urlretrieve, because I tried downloading the file with wget, and got the following: [irmen at isengard tmp]$ wget -S http://cvs.sourceforge.net/cvstarballs/boost-cvsroot.tar.bz2 --20:38:11-- http://cvs.sourceforge.net/cvstarballs/boost-cvsroot.tar.bz2 => `boost-cvsroot.tar.bz2.1' Resolving cvs.sourceforge.net... 66.35.250.207 Connecting to cvs.sourceforge.net[66.35.250.207]:80... connected. HTTP request sent, awaiting response... 1 HTTP/1.1 200 OK 2 Date: Sun, 07 Nov 2004 19:38:15 GMT 3 Server: Apache/2.0.40 (Red Hat Linux) 4 Last-Modified: Sat, 06 Nov 2004 15:11:39 GMT 5 ETag: "b63d5b-25c3808-687d80c0" 6 Accept-Ranges: bytes 7 Content-Length: 39598088 8 Content-Type: application/x-bzip2 9 Connection: close 31% [=======================> ] 12,665,616 60.78K/s ETA 03:55 20:40:07 (111.60 KB/s) - Connection closed at byte 12665616. Retrying. --20:40:08-- http://cvs.sourceforge.net/cvstarballs/boost-cvsroot.tar.bz2 (try: 2) => `boost-cvsroot.tar.bz2.1' Connecting to cvs.sourceforge.net[66.35.250.207]:80... connected. HTTP request sent, awaiting response... ....... so the remote server just closed the connection halfway trough! I suspect that a succesful download is sheer luck. Also, the download loop in urllib looks fine to me. It only stops when the read() returns an empty result, and that means EOF. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-26 22:04 Message: Logged In: YES user_id=80475 Followed the same procedure (no chdir, add a hook) but bombed out at 9.1Mb: . . . (1117, 8192, 34520156) ('boost-cvsroot.tar.bz2', ) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-26 20:52 Message: Logged In: YES user_id=31435 Hmm. I don't know anything about this, but thought I'd just try it. Didn't chdir(), did add a reporthook: def hook(*args): print args WinXP Pro SP1, current CVS Python, cable modem over a wireless router. Output looked like this: (0, 8192, 34520156) (1, 8192, 34520156) (2, 8192, 34520156) ... (4213, 8192, 34520156) (4214, 8192, 34520156) (4215, 8192, 34520156) Had the whole file when it ended: > wc boost-cvsroot.tar.bz2 125368 765656 34520156 boost-cvsroot.tar.bz2 *Maybe* adding the reporthook changed timing in some crucial way. Don't know. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-26 19:09 Message: Logged In: YES user_id=80475 Confirmed. On Py2.4 (current CVS), I got 12.7 Mb before the connection closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016880&group_id=5470 From noreply at sourceforge.net Wed Aug 24 21:30:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 12:30:47 -0700 Subject: [ python-Bugs-1267540 ] _register is not safe Message-ID: Bugs item #1267540, was opened at 2005-08-23 16:29 Message generated for change (Comment added) made by reowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267540&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: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: _register is not safe Initial Comment: The _register function is not safe. It uses the following code to generate a unique string to identify a python callable entity: f = CallWrapper(func, subst, self).__call__ name = repr(id(f)) It then adds the function name if func has a __name__ attribute, but bound methods don't have that, and it is bound methods that cause the problem because they don't have a constant id number unless somebody bothers to keep an explicit reference to the bound reference around (keeping a reference to the object itself isn't enough). For example: class foo: def meth1(self): pass def meth2(self): pass f = foo() print id(f) print id(f.meth1) print id(f.meth2) Odds are good that the last two printed numbers will be the same even though they are for two different bound methods. The id of f will persist and remain unique as long as the object exists, but the id of its bound methods will not. Even though one can call the bound methods as long as the object persists. I don't know how to best handle this. Possibilities include: - Use hash(func) instead of id(func). I don't know enough about the built in hash to know if that is safe. Certainly it is the right idea. One wants a function that has the same value if the callable entity is the same and a different value otherwise. - Generate a new hash function that is sure to work. "paolino" suggested the following hash function for bound methods (when I first asked about this problem on comp.lang.python): id(boundMethod.im_self)^id(boundMethod.im_func) this is probably the simplest solution if hash itself isn't safe, but it requires a some fiddling to figure out what kind of callable entity one has, and thus what hash equation is suitable. - Keep a reference to the callable entity, so its id number cannot be reused. That sounds hard to do safely; it would be all too easy to introduce a memory leak. It can probably be done fairly easily for the case cleanup=1, but there is code that uses cleanup=0 (including bind_all and bind_class). -- Russell ---------------------------------------------------------------------- >Comment By: Russell Owen (reowen) Date: 2005-08-24 12:30 Message: Logged In: YES user_id=431773 You are right. I should have realized that cratecommand kept a reference to the function (else how could it call it?). I replicated _register so as to not use a Tkinter internal function, and at some point ended up taking the id of the wrong thing. Sorry for the false alarm. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-23 22:34 Message: Logged In: YES user_id=21627 Can you provide a test case that demonstrates the problem? I don't think there is anything wrong with that code. We don't take the id of func, we take the id of f, where f is CallWrapper(...).__call__. f gets then passed to tk.createcommand, which in turn puts f into PythonCmd_ClientData. So as long as the Tcl command lives, f (which is indeed a method) is referenced, which in turn means that no other method can have the same id. You are also wrong that the name is not added for bound methods. It looks at im_func, and then takes the name of the function in the bound method. >>> f.meth1.im_func.__name__ 'meth1' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267540&group_id=5470 From noreply at sourceforge.net Wed Aug 24 21:45:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 12:45:46 -0700 Subject: [ python-Bugs-1267540 ] _register is not safe Message-ID: Bugs item #1267540, was opened at 2005-08-24 01:29 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267540&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: Tkinter Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: _register is not safe Initial Comment: The _register function is not safe. It uses the following code to generate a unique string to identify a python callable entity: f = CallWrapper(func, subst, self).__call__ name = repr(id(f)) It then adds the function name if func has a __name__ attribute, but bound methods don't have that, and it is bound methods that cause the problem because they don't have a constant id number unless somebody bothers to keep an explicit reference to the bound reference around (keeping a reference to the object itself isn't enough). For example: class foo: def meth1(self): pass def meth2(self): pass f = foo() print id(f) print id(f.meth1) print id(f.meth2) Odds are good that the last two printed numbers will be the same even though they are for two different bound methods. The id of f will persist and remain unique as long as the object exists, but the id of its bound methods will not. Even though one can call the bound methods as long as the object persists. I don't know how to best handle this. Possibilities include: - Use hash(func) instead of id(func). I don't know enough about the built in hash to know if that is safe. Certainly it is the right idea. One wants a function that has the same value if the callable entity is the same and a different value otherwise. - Generate a new hash function that is sure to work. "paolino" suggested the following hash function for bound methods (when I first asked about this problem on comp.lang.python): id(boundMethod.im_self)^id(boundMethod.im_func) this is probably the simplest solution if hash itself isn't safe, but it requires a some fiddling to figure out what kind of callable entity one has, and thus what hash equation is suitable. - Keep a reference to the callable entity, so its id number cannot be reused. That sounds hard to do safely; it would be all too easy to introduce a memory leak. It can probably be done fairly easily for the case cleanup=1, but there is code that uses cleanup=0 (including bind_all and bind_class). -- Russell ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2005-08-24 21:30 Message: Logged In: YES user_id=431773 You are right. I should have realized that cratecommand kept a reference to the function (else how could it call it?). I replicated _register so as to not use a Tkinter internal function, and at some point ended up taking the id of the wrong thing. Sorry for the false alarm. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-24 07:34 Message: Logged In: YES user_id=21627 Can you provide a test case that demonstrates the problem? I don't think there is anything wrong with that code. We don't take the id of func, we take the id of f, where f is CallWrapper(...).__call__. f gets then passed to tk.createcommand, which in turn puts f into PythonCmd_ClientData. So as long as the Tcl command lives, f (which is indeed a method) is referenced, which in turn means that no other method can have the same id. You are also wrong that the name is not added for bound methods. It looks at im_func, and then takes the name of the function in the bound method. >>> f.meth1.im_func.__name__ 'meth1' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267540&group_id=5470 From noreply at sourceforge.net Wed Aug 24 22:05:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 13:05:01 -0700 Subject: [ python-Bugs-1269051 ] atexit not called for pythonservice (win32) Message-ID: Bugs item #1269051, was opened at 2005-08-24 13:05 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=1269051&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hari Krishna Dara (haridsv) Assigned to: Nobody/Anonymous (nobody) Summary: atexit not called for pythonservice (win32) Initial Comment: I have a couple of functions registered with atexit which work fine when the program is executed on command-line. But when I run the same as a windows service, and stop the service using service interface, these hooks never get call backs. The service does exit normally (at least my program doesn't do os._exit() and there are no exceptions). I am using ActiveState's distribution of python, but I would imagine this is non-specific. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1269051&group_id=5470 From noreply at sourceforge.net Wed Aug 24 22:05:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 13:05:30 -0700 Subject: [ python-Feature Requests-567972 ] Missing 4 socket object properties Message-ID: Feature Requests item #567972, was opened at 2002-06-12 13:56 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&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: None Status: Open Resolution: None Priority: 5 Submitted By: Graham Horler (grahamh) >Assigned to: Raymond Hettinger (rhettinger) Summary: Missing 4 socket object properties Initial Comment: The C socketmodule has a struct PySocketSockObject, with family, type and proto members. These would be terribly helpful to have access to in Python, when implementing some generic socket helper functions. The "blocking" flag could also be made available, but would require some extra coding. (I'm using Python 2.1.3 under Linux 2.4.16, so I cannot extend the socket class itself ((as in py2.2)), and don't want to slow down sockets with a complete wrapper, as I use them heavily.) Thanks, Graham. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-24 22:05 Message: Logged In: YES user_id=1188172 Attaching new patch. Following changes: - getfamily(), gettype(), getproto() functions of _socketobject which map to - family, type, proto members of socket._sock - timeout member of socket._sock - documentation update - test suite update Please review. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-24 17:24 Message: Logged In: YES user_id=21627 grahamh, I take it that your answer to the question "would you like to implement a patch?", is "no". I agree with parts of the review: these things should be added to the _socketobject. Also, socket objects have one more attribute, sock_timeout, which might be worth exposing. I also wonder what style of API should be used. All other state access goes through get-methods(), which all start with get except for fileno(). Adding properties would introduce another API style, so -1. As for blocking: this sounds like a different feature request, as this is not a member of struct PySocketSockObject. So I would close this request as soon as the three attributes are implemented; if you then still want the getblocking() method, you should write another feature request. In addition, this patch lacks documentation and test suite changes. Unassigning myself, as I won't take any further action for the moment. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2005-07-20 16:47 Message: Logged In: YES user_id=543663 The patch applies, compiles, runs OK for me (thanks). However it does not add access to the blocking flag. Under Linux I can go: fcntl.fcntl(fd, fcntl.F_GETFL) & os.O_NDELAY != 0 But this is not portable, and is probably repeating code. Also the 3 added members are not available from an instance of the _socketobject wrapper, you have to go mysock._sock.family. (The _socketobject wrapper in socket.py is a little bizarre IMVHO.) Perhaps they could be added using instances of property(). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 15:49 Message: Logged In: YES user_id=1188172 Attaching a patch which implements the three members of _socket.socket. Please review. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-06-15 15:21 Message: Logged In: YES user_id=21627 Sounds good. Would you like to produce a patch implementing this feature? ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-06-12 14:00 Message: Logged In: YES user_id=543663 Oh yes, the repr of a socket object includes the missing info, so to get hold of the family, I go: int(repr(sock).split(' ')[3].split('=')[1][:-1]) Similar for type and protocol, not nice! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470 From noreply at sourceforge.net Wed Aug 24 22:33:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 13:33:50 -0700 Subject: [ python-Bugs-1016563 ] urllib2 bug in proxy auth Message-ID: Bugs item #1016563, was opened at 2004-08-26 09:14 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016563&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: Closed >Resolution: Fixed Priority: 6 Submitted By: Christoph Mussenbrock (mussenbrock) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: urllib2 bug in proxy auth Initial Comment: in urllib2.py: line 502 should be: ... user_pass = base64.encodestring('%s:%s' % (unquote (user), unquote(password))).strip() the '.strip()' is missing in the current version ("2.1"). this makes an additonal '\n' at the end of user_pass. So there will be an empty line in the http header, which is buggy. (see also line 645, where the .strip() is right in place!). Best regards, Christoph ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-24 22:33 Message: Logged In: YES user_id=1188172 Thanks for the report, committed as Lib/urllib2.py r1.85, r1.77.2.2. ---------------------------------------------------------------------- Comment By: Pieter Van Dyck (pietervd) Date: 2005-06-14 17:39 Message: Logged In: YES user_id=1240437 I've run into the same bug so allow me to comment. client environment: windows XP target: Apache/1.3.33 (Unix) checked on: python 2.3.4, 2.3.5, 2.4.1 To reproduce: # from urllib2 import ... proxy = {"http":"http://user:pwd at proxy:port"} opener =build_opener(ProxyHandler(proxy)) install_opener( opener ) req = Request(coolurl) # construct base64string = base64.encodestring('%s:%s' % (site_user, site_pwd))[:-1] authheader = "Basic %s" % base64string req.add_header("Authorization", authheader) urlopen( req ) Symptoms: authentication failed on coolurl (HTTPError 401) Fix: Applying the patch solves the problem for me It appears as if the receiving server treats the empty line as the end of the header even though it strictly shouldn't. HTH Pieter ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-01-29 22:50 Message: Logged In: YES user_id=113328 The change was introduced by revision 1.32 of the file, from patch 527518. There's no mention of removing strip() there, so I suspect it was an accident. The strip() is still missing in CVS HEAD. I can see the problem, in theory (base64.encodestring returns a string with a terminating newline). However, I cannot reproduce the problem. Can the original poster provide a means of verifying the problem? It may be useful as a test case. Regardless, the change seems harmless, and can probably be applied. I attach a patch against CVS HEAD: --- urllib2.py.orig 2005-01-09 05:51:49.000000000 +0000 +++ urllib2.py 2005-01-29 21:31:49.000000000 +0000 @@ -582,7 +582,8 @@ if ':' in user_pass: user, password = user_pass.split(':', 1) user_pass = base64.encodestring('%s:%s' % (unquote(user), - unquote(password))) + unquote(password)) + ).strip() req.add_header('Proxy-authorization', 'Basic ' + user_pass) host = unquote(host) req.set_proxy(host, type) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016563&group_id=5470 From noreply at sourceforge.net Wed Aug 24 23:15:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 14:15:13 -0700 Subject: [ python-Bugs-1263656 ] IDLE on Mac Message-ID: Bugs item #1263656, was opened at 2005-08-18 22:35 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263656&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: IDLE Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE on Mac Initial Comment: Copying code from some browsers into IDLE on the Mac can leave the file with only \r (13) at the ends of lines (Safari doesn't seem to have this problem). Then checksyntax() in ScriptBinding.py fails to convert these into \n (10), and compile() fails. The effect is that a program which Python is willing to run gets a syntax error in IDLE. I think the fix is in checksyntax() to add after source = re.sub(r"\r\n", "\n", source) the following statement, which converts unaccompanied \r's into \n's:: source = re.sub(r"\r", "\n", source) I've tried this and it works, but someone with a better overview of end-of-line issues in Python should think through whether this is the appropriate fix. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-08-24 17:15 Message: Logged In: YES user_id=149084 That should be NEWS.txt 1.62 Scriptbinding 1.31 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-08-23 13:41 Message: Logged In: YES user_id=149084 Backported, ScriptBinding.py 1.28.4.1 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-08-22 22:48 Message: Logged In: YES user_id=149084 ScriptBinding 1.62. Backport to 2.4.2 Seems harmless. Please check. IDLE retains line endings when loading code from a file. In this case OS X uses \r in the GUI and \r\n in the OS. Heaven knows what happens with fink/X11. IDLE expects \n internally, line endings are converted on I/O. What is your os.linesep under the conditions you mentioned? Regular expression pattern elements like r'\n' match the corresponding special characters; both bytes have to be in the pattern. You can do it by escaping the backslash in a regular string, '\n', which is also two bytes. But it's easier to use raw strings with regular expressions. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2005-08-19 12:16 Message: Logged In: YES user_id=34881 I should have said that this is in the environment of running IDLE on Mac OSX 10.4 under X11, using the fink distribution. I should also say that there seem to be issues not only of compiling but also of editing/display. In a browser, click on a .py file, select all the text, copy, paste into IDLE. With Safari, it looks right and it runs. With NetScape, it displays all on one line, and it doesn't run (syntax error). I haven't studied the actual code to see what if anything IDLE does to attempt to detect the nature of text pasted into an edit window, but clearly it's different coming from two popular browsers. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2005-08-19 00:23 Message: Logged In: YES user_id=34881 A footnote: Now I don't understand why the substitution searches for r"\r\n", since this would seem to be the raw string which represents slash, r, slash, n, not the two-character string "\r\n"....?? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263656&group_id=5470 From noreply at sourceforge.net Thu Aug 25 00:21:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 15:21:15 -0700 Subject: [ python-Bugs-735248 ] urllib2 parse_http_list wrong return Message-ID: Bugs item #735248, was opened at 2003-05-09 16:09 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735248&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: urllib2 parse_http_list wrong return Initial Comment: parse_http_list should split a string on commas, unless the commas are within a quoted-string. (It allows only the "" quote, and not the single-quote, but this seems to follow the RFC.) If there are not quoted-strings, it repeats the first tokens as part of subsequent tokens. parse_http_list ('a,b') => ['a','a,b'] It should return ['a','b'] parse_http_list ('a,b,c') => ['a','a,b','a,b,c'] It should return ['a','b','c'] Patch: On (cvs version) line 882, when no quote is found and inquote is false, reset the start position to after the comma. if q == -1: if inquote: raise ValueError, "unbalanced quotes" else: list.append(s[start:i+c]) i = i + c + 1 start = i #New line continue ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 00:21 Message: Logged In: YES user_id=1188172 Fixed the algorithm in Lib/urllib2.py r1.86, 1.77.2.3 Added testcase in Lib/test/test_urllib2.py r1.22, 1.19.2.1 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-11-10 00:53 Message: Logged In: YES user_id=261020 This function doesn't deal with quoting of characters inside quoted-strings, either. In particular, it doesn't deal with \", \, and \, (see RFC 2616, section 2.2, quoted-pair). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735248&group_id=5470 From noreply at sourceforge.net Thu Aug 25 08:07:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Aug 2005 23:07:28 -0700 Subject: [ python-Bugs-1251631 ] Python 2.4.1 crashes when importing the attached script Message-ID: Bugs item #1251631, was opened at 2005-08-04 09:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251631&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: Closed >Resolution: Fixed Priority: 7 Submitted By: Viktor Ferenczi (complex) Assigned to: Martin v. L?wis (loewis) Summary: Python 2.4.1 crashes when importing the attached script Initial Comment: OS: WinXP Prog. ENG SP1 Python: 2.4.1 MSI installer downloaded from python.org Python crashes or rarely raises MemoryError or SyntaxError when trying to import/execute the script attached. The behaviour changes when some lines are modified, but mostly crashes the python process with a memory access violation. The python process used 4.2Mbytes of system memory when crashed. There were more than 500Mbytes free. Register dump: EAX = 00A8CC61 EBX = 0000000A ECX = 00000000 EDX = 00000000 ESI = 00A10DA0 EDI = 00000022 EIP = 1E0A7F10 ESP = 0021FD98 EBP = 00000222 EFlags = 00000293 Other registers are irrelevant. The bug occured at the last line of the following instruction sequence because ECX was zero: 1E0A7EB2 66 C7 02 0A 00 mov word ptr [edx],0Ah 1E0A7EB7 8B 46 08 mov eax,dword ptr [esi+8] 1E0A7EBA 6A 00 push 0 1E0A7EBC 50 push eax 1E0A7EBD FF 15 B4 31 0C 1E call dword ptr ds:[1E0C31B4h] 1E0A7EC3 89 46 08 mov dword ptr [esi+8],eax 1E0A7EC6 8A 48 FF mov cl,byte ptr [eax-1] 1E0A7EC9 83 C4 08 add esp,8 1E0A7ECC 80 F9 0A cmp cl,0Ah 1E0A7ECF 0F 85 72 FF FF FF jne 1E0A7E47 1E0A7ED5 BB 0A 00 00 00 mov ebx,0Ah 1E0A7EDA 8B 0E mov ecx,dword ptr [esi] 1E0A7EDC 8B 54 24 0C mov edx,dword ptr [esp+0Ch] 1E0A7EE0 8D 04 11 lea eax,[ecx+edx] 1E0A7EE3 89 46 04 mov dword ptr [esi+4],eax 1E0A7EE6 8B 46 08 mov eax,dword ptr [esi+8] 1E0A7EE9 83 E8 02 sub eax,2 1E0A7EEC 3B C1 cmp eax,ecx 1E0A7EEE 72 0F jb 1E0A7EFF 1E0A7EF0 80 38 0D cmp byte ptr [eax],0Dh 1E0A7EF3 75 0A jne 1E0A7EFF 1E0A7EF5 C6 00 0A mov byte ptr [eax],0Ah 1E0A7EF8 40 inc eax 1E0A7EF9 C6 00 00 mov byte ptr [eax],0 1E0A7EFC 89 46 08 mov dword ptr [esi+8],eax 1E0A7EFF 39 5E 14 cmp dword ptr [esi+14h],ebx 1E0A7F02 75 21 jne 1E0A7F25 1E0A7F04 8B 4E 04 mov ecx,dword ptr [esi+4] 1E0A7F07 3B 4E 08 cmp ecx,dword ptr [esi+8] 1E0A7F0A 0F 84 24 FD FF FF je 1E0A7C34 1E0A7F10 0F B6 01 movzx eax,byte ptr [ecx] It may be possible to find the source line related to this bug by searching for this code in the retail python.exe then looking up the address in the map file produced by the compiler (if enabled). I can run the script with a debug version of python.exe. Please send me information about how to download a debug version for Windows. Note: I've tried to search this bug in the bug database, but it's not specific enough to find an exact match. No viruses nor spyware found on my machine using multiple antivirus/antispyware product. No memory errors found in 6 hours. I use LF (UNIX type) line ends on Windows to prevent errors when my scripts copied and edited on a Linux box. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-25 08:07 Message: Logged In: YES user_id=21627 This is now fixed for 2.4.2, which will say File "python_2.4.1_crash.py", line 225 SyntaxError: 'ascii' codec can't decode byte 0xc1 in position 0: ordinal not in range(128) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-08 09:17 Message: Logged In: YES user_id=89016 The line number problem might be related to http://www.python.org/sf/1178484 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-08-07 19:40 Message: Logged In: YES user_id=31435 Note that it's not legal input: there's a non-ASCII character in line 225, which conflicts with the explicit # -*- coding: ascii -*-" directive near the top of file. Get rid of the non-ASCII character, and it seems to load fine. Current Python HEAD (2.4.2 development) gives a different outcome: File "pycrash.py", line 222 SyntaxError: unknown decode error That's peculiar too, because the offending character is actually on line 225, and because "unknown decode error" is unhelpful. Python 2.3 at least got the line number right: File "pycrash.py", line 225 SyntaxError: unknown decode error The best error report is gotten by deleting the encoding directive instead (using 2.4.1 here): sys:1: DeprecationWarning: Non-ASCII character '\xc1' in file pycrash.py on line 224, but no encoding declared; see http ://www.python.org/peps/pep-0263.html for details Assigning to Martin under the vague recollection that he knows most about the encoding implementation. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-08-04 09:21 Message: Logged In: YES user_id=142612 The bug could be in python.dll, of course. I need a debug version of python.dll. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251631&group_id=5470 From noreply at sourceforge.net Thu Aug 25 09:30:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 00:30:53 -0700 Subject: [ python-Bugs-868864 ] 8-bit string literal with iso8859 coding => crash Message-ID: Bugs item #868864, was opened at 2004-01-01 18:30 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868864&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Martin v. L?wis (loewis) Summary: 8-bit string literal with iso8859 coding => crash Initial Comment: Environment: Python 2.3.3, built from unmodified out-of-the-tarball sources (./configure, make, make install) Red Hat Linux 7.3, SMP build from source (2 Athlon CPUs) Symptom: python out.py Segmentation fault ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-25 09:30 Message: Logged In: YES user_id=21627 This bug is now fixed in the CVS, for 2.5 and 2.4.2. ---------------------------------------------------------------------- Comment By: Mike Rozhnov (rozhnov) Date: 2004-04-22 14:00 Message: Logged In: YES user_id=1026824 Is it possible to fix this bug before Python 2.4 release? For now choices when using 8-bit literals are: - always receive warning about PEP-263 - possible crash after editing any source module with 8-bit literals in any time Sorry. I can't fix this bug myself (don't have and use Visual C). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-16 15:44 Message: Logged In: YES user_id=21627 It's much worse than off-by-one. fp_readl reads size-1 bytes from the input stream, reencodes them as UTF-8, and tries to fit them into size bytes. In the example, it tries to put 8860 bytes into space for 8192 bytes. I believe fp_readl should extend the buffer, using code similar to tok_nextc. Alternatively, fp_readl could, conservatively, request only size/4 bytes from the underlying input stream, knowing that, for most encodings, converting to UTF-8 will increase the size at worst by a factor of 4. The assertion that the result still fits should then become a FatalError. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-01-02 09:58 Message: Logged In: YES user_id=92222 Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on win32 Windows 2kSP4 Effect is the same - Python crashes with "memory can not be written". ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-01-01 20:53 Message: Logged In: YES user_id=33168 Looks like there may be an off-by-1 error in the implementation of PEP263. Attached is a valgrind report. Martin, do you have any ideas? ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2004-01-01 18:32 Message: Logged In: YES user_id=8861 'make test' ran with no problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868864&group_id=5470 From noreply at sourceforge.net Thu Aug 25 09:39:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 00:39:15 -0700 Subject: [ python-Feature Requests-1123660 ] add SHA256/384/512 to lib Message-ID: Feature Requests item #1123660, was opened at 2005-02-16 05:14 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1123660&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: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add SHA256/384/512 to lib Initial Comment: According to http://www.schneier.com/blog/archives/2005/02/sha1_broken.html some Chinese researchers have just announced a break against SHA1. These are the same guys who broke MD5 a few months ago and the SHA1 break, while not exactly expected, is also not really shocking at this point. The break allows finding a free collision in the full SHA1 in O(2**69) operations, still an awful lot in practice. So nobody should panic. But it means that new applications probably want to use SHA256, SHA384, or SHA512, which were standardized by NIST at the same time AES was standardized, as successors to SHA1. The hash lengths are 256, 384, or 512 bits respectively, and correspond to 2x the AES key lengths of 128, 192, or 384 bits. Their design is strengthened from SHA1 to resist attacks like this. On the other hand, they are slower than SHA1. Anyway, there are various free implementations of the algorithms around (libtomcrypt.org has some public domain versions) so it should be straightforward enough to transplant the Python C API wrapper from sha.c to it. I think it's reasonable to put these all into the existing sha module, rather than make a new module. They could be called by adding an optional arg to sha.new: x = sha.new(data, 256).digest() would find the sha256 digest, etc. Note that sha512 and sha384 are the same algorithm, with different initial parameters and with 128 bits discarded for sha384. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 09:39 Message: Logged In: YES user_id=1188172 This should be addressed by the addition of the hashlib module in 2.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-20 11:52 Message: Logged In: YES user_id=80475 "Break" is a bit of an over-statement. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 18:45 Message: Logged In: YES user_id=593130 Ok, next time.... You might want to look at https://sourceforge.net/tracker/index.php? func=detail&aid=1121611&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 17:55 Message: Logged In: YES user_id=72053 Well, I don't see an obvious way to reclassify this item. If someone knows how to do it, please go ahead. I sent an email to the lawyer and haven't gotten a response yet. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 17:14 Message: Logged In: YES user_id=593130 Addition to the previous: current does not necessarily mean final. I am not a party to any ongoing non-public discussion of these issues. Over and out. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 06:25 Message: Logged In: YES user_id=593130 Here is the top of this page: Project: Bugs: Trackers and here is the beginning of the email sent to me: Bugs item #1123660, was opened at 2005-02-16 04:14 I found the explanation: on https://sourceforge.net/tracker/?group_id=5470 you need to click RFE instead of Bugs on this line: Summary | Admin | Home Page | Tracker | Bugs | Patches | RFE | When you click Bugs, Feature Request shows up under Group because it was put there before there was a separate RFE list and now, I remember, it cannot be removed. (SF 'feature') But it would be if it could be. --- Yes, that is the lawyer and article. Yes, I noticed the discrepancy 'PD not real' and current PEP PD policy, but refrained from saying anything yet. I have no more to do with those and other docs than you do. Contributor agreements: your link is to a 3 1/2 year old draft, badly misleading, but first hit on 'contributor' search. I have suggested its removal. Current, I believe, is http://www.python.org/psf/contrib which links to http://www.python.org/moin/PythonSoftwareFoundationLicen seFaq and http://www.python.org/psf/contrib-form.html ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 04:33 Message: Logged In: YES user_id=72053 I couldn't find the "Contributions" section of Python.org; got a url? I did find PEP 241 says public domain is a legitimate choice of license, and also the PSF patch submission agreement near the bottom of http://www.python.org/psf/psf-contributor-agreement.html suggests releasing the patch to the PD (but only if the contributor wrote the entire patch, which wouldn't apply to wrapping some existing public domain work). Also a lot of the PEP's are released as PD. So maybe you want to revisit all those docs, if there's now some problem with PD releases. I think the Linuxjournal article you refer to might be http://www.linuxjournal.com/article/6225 . It is just bizarre. Is that the same lawyer? It says he also advises the OSI, so I might email him with that Bernstein cite. This tracker item clearly says "Feature request" in the "Group" pulldown when I look at it in Sourceforge. That's the way I entered it and if it's showing up differently for you, something is going wrong somewhere. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 03:52 Message: Logged In: YES user_id=593130 Yes, feature request = RFE. However, this somehow got into the tracker as a bug item, not an RFE item. Check the top of the page or beginning of email subject line or body text. Hence my comment. My FYI legal issue summary was based on a PyDev thread within the last week and the Contribution pages at python.org. I have no opinion on the lawyer dispute over PD. PSF's lawyer wrote his opinion in a LinuxJournal piece referenced in that thread. PSF Board is inclined to follow advice paid for. Yes, Sha module should be maintained by one person. Hope one of crypto people sees and responds to this item. There is also a current PyDev thread about sha?, md5, ssl, and licensing, but I barely paid attention. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 02:43 Message: Logged In: YES user_id=72053 Addendum: Note that this RFE is an enhancement request for the sha module. Therefore I think the best way to triage it is to assign it to the current sha module maintainer and let him decide what if anything to do about it. If he accepts a patch (or does one himself), it's logical for him to also take ownership of the patch at that point. Sha is a relatively uncomplicated module and it doesn't make much sense for it to have multiple maintainers. I don't think any harm will be done if this stays open for a while until someone gets around to doing a patch. But sooner or later there will be a need for it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 02:31 Message: Logged In: YES user_id=72053 Oops, correction to previous, US court ruling was from 9th circuit, not Supreme Court. However it doesn't appear to be a matter of controversy. Prof. Lessig's pages about Creative Commons also say that releasing stuff into the PD is valid and I think Prof. Moglen has said something similar. The PSF lawyer might want to talk to Lessig or Moglen if there's some uncertainty. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 02:27 Message: Logged In: YES user_id=72053 1. I submitted it as a feature request and thought that was the same thing as an RFE. If it needs to be reclassified in some way, let me know how to do that. 2. The library I mentioned was explicitly released into the public domain by the author. I'd be interested to know what the PSF's lawyer's objection is to using public domain code. The OSF license list doesn't include public domain but I think that's just an oversight. The FSF's license list says public domain code is fine as free software. http://cr.yp.to/publicdomain.html cites a US Supreme Court ruling that releasing stuff into the PD is perfectly legally valid (at least in the US). Is the lawyer complaining that there's some obstacle in other countries? If you have a written opinion from him/her I'd appreciate seeing it. I've heard this claim before but it has always sounded bogus to me. 3. I'm not at the moment versed enough in the Python C API to be able to do this patch quickly, and I have other things going on so I can't spend time on it right now. I'm also not willing to be the long-term maintainer even if I do the patch. I submitted the report mostly to give the lib. maintainers a heads-up to the new development. SHA256/384/512 (collectively known as SHA2) has been on the horizon for a long time as an SHA1 successor, but the recent results against SHA1 are going to make SHA2 into a higher priority addition than before. Other people are going to be asking for it and its absence will become a somewhat serious deficiency in the stdlib. So, someone interested in this kind of thing might want to look into it. 4. The SHA2 patches should be pretty simple. SHA2 is just like SHA1 in terms of API and basic functionality. The actual algorithms are different and the lengths of the returned hash are different but that should be a straightforward matter of adding wrappers for the new functions. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 01:55 Message: Logged In: YES user_id=593130 This is, of course, an RFE -- request for enhancement -- and not at all a bug report. Will SF let you reclassify it? I suspect your request is reasonable, but if you leave it here, it may get closed as Invalid -- not a bug. If you really want this to happen, I suspect you know the drill: submit a patch and help review others. What you may not know it that 'public domain' is mostly not acceptible for contributions. The PSF's paid lawyer considers it bogus for modern creations other than government work. What the PSF does want is stuff licensed under specific open source licenses and specifically contributed to Python by the author. There also needs to be a code maintainer. Getting all this takes more work that just visiting a site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1123660&group_id=5470 From noreply at sourceforge.net Thu Aug 25 09:59:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 00:59:33 -0700 Subject: [ python-Feature Requests-927543 ] "with self:" statement Message-ID: Feature Requests item #927543, was opened at 2004-04-01 16:36 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=927543&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: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Thomas Dunne (tomdunne) Assigned to: Nobody/Anonymous (nobody) Summary: "with self:" statement Initial Comment: please forgive if this is documented somewhere; I looked and searched and could not find any up to date PEPs or comments about the status of this idea. I managed to find a thread from 2002 that talked about this in great detail: http://mail.python.org/pipermail/python-list/2002-July/112888.html but there was no conclusion... I know it's not a new idea and it shows up often... but here goes: How about a "with self:" statement, but more in the style of (forgive) VB then Pascal, ie referenced items in the self instance are preceded with a dot. present syntax: with self:   returnvalue = self.x + self.y * self.width proposed syntax: with self:   returnvalue = .x + .y * .width If no preceding dot is used, you run into an ambiguity when assigning values. How do you know if the variable is to be assigned in self or to an object in a higher scope... the preceding dot avoids that problem since it explicitly tags self items. (using nested "with" statements will lead to the same problem when assigning values. Assignment will have to be to the innermost "with object". Reading values should work ok though. ) I understand that I could just simply use "s." instead of "self." or assign all needed values in one preceding line:   x,y,width = self.x, self.y, self.width This is a question that shows up every so often, the points made in the thread are good: http://mail.python.org/pipermail/python-list/2002-July/113831.html has this been recently discussed? is there a patch or PEP? (I might be able to provide a patch...) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 09:59 Message: Logged In: YES user_id=1188172 As "with" is taken now, this is out of date. If you find another reasonable keyword, feel free to reopen, but keep in mind that it still needs a PEP. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-21 08:02 Message: Logged In: YES user_id=80475 Guido occasionally mentions this as a possibility, so writing a PEP would be a useful next step. Though simple, this would change the feel of the language. Accordingly, it would need much public discussion before advancing. ---------------------------------------------------------------------- Comment By: Thomas Dunne (tomdunne) Date: 2004-05-05 23:01 Message: Logged In: YES user_id=1005553 Hey Greg, completely OT, but thought you should know: your sourceforge address redirect isn't correct! I sent an email to gward at users.sourceforge.net and the host (don't want to post for everyone to see here) responded that the redirected address didn't exist... ---------------------------------------------------------------------- Comment By: Thomas Dunne (tomdunne) Date: 2004-05-05 22:48 Message: Logged In: YES user_id=1005553 Hey Greg, thanks for the suggestion! I posted a PEP to peps at python.org, flame on! ;) (want a copy?) ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2004-05-05 03:45 Message: Logged In: YES user_id=14422 A change of this magnitude demands a PEP. I don't recall having seen one, but I haven't been following python-dev for a while. If you want to do the right thing, write up a PEP and submit it to python-dev for the obligatory shooting-down-in-flames. Document the reasons why the feature was rejected in the PEP, and then the next time someone asks for it, your PEP can be trotted out. And don't take it personally when your idea gets shot down in flames. (Heck, who knows, maybe the python-dev crew will latch on and someone will implement it. But I doubt it...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=927543&group_id=5470 From noreply at sourceforge.net Thu Aug 25 10:06:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 01:06:23 -0700 Subject: [ python-Feature Requests-847778 ] Keyword similar to " global" for nested scopes want Message-ID: Feature Requests item #847778, was opened at 2003-11-23 19:51 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=847778&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: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Jozef Behran (jojoworks) Assigned to: Nobody/Anonymous (nobody) >Summary: Keyword similar to "global" for nested scopes want Initial Comment: I suggest you adding a keyword, say "nested" to explicitly bound the name to the upper level of nested scope. This keyword would be similar to "global", which bounds the name to the top level. See the attachment for the idea. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 10:06 Message: Logged In: YES user_id=1188172 How would you make sure that the outer scope even exists at the time the code is run? dubnerm's comment is a valid point, too. That's the same problem as break 2 or such. Therefore, closing as rejected. ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-12-04 07:01 Message: Logged In: YES user_id=39274 Hm-m. What about outer scope for outer scope? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=847778&group_id=5470 From noreply at sourceforge.net Thu Aug 25 10:06:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 01:06:26 -0700 Subject: [ python-Feature Requests-847778 ] Keyword similar to " global" for nested scopes want Message-ID: Feature Requests item #847778, was opened at 2003-11-23 19:51 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=847778&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: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Jozef Behran (jojoworks) Assigned to: Nobody/Anonymous (nobody) Summary: Keyword similar to "global" for nested scopes want Initial Comment: I suggest you adding a keyword, say "nested" to explicitly bound the name to the upper level of nested scope. This keyword would be similar to "global", which bounds the name to the top level. See the attachment for the idea. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 10:06 Message: Logged In: YES user_id=1188172 How would you make sure that the outer scope even exists at the time the code is run? dubnerm's comment is a valid point, too. That's the same problem as break 2 or such. Therefore, closing as rejected. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 10:06 Message: Logged In: YES user_id=1188172 How would you make sure that the outer scope even exists at the time the code is run? dubnerm's comment is a valid point, too. That's the same problem as break 2 or such. Therefore, closing as rejected. ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-12-04 07:01 Message: Logged In: YES user_id=39274 Hm-m. What about outer scope for outer scope? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=847778&group_id=5470 From noreply at sourceforge.net Thu Aug 25 11:04:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 02:04:14 -0700 Subject: [ python-Bugs-1257255 ] tarfile local name is local, should be abspath Message-ID: Bugs item #1257255, was opened at 2005-08-12 04:26 Message generated for change (Settings changed) made by birkenfeld 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: Martin v. L?wis (loewis) 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. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 11:04 Message: Logged In: YES user_id=1188172 The patch has been reversed, so reopening. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-24 08:08 Message: Logged In: YES user_id=21627 This was fixed with said patch. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-08-17 14:34 Message: Logged In: YES user_id=642936 Thank you very much for your report. I added patch #1262036 that ought to fix the problem. ---------------------------------------------------------------------- Comment By: Martin Blais (blais) Date: 2005-08-15 19:34 Message: Logged In: YES user_id=10996 Oops, that was silly. My apologies. Here goes the file... ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-08-15 13:39 Message: Logged In: YES user_id=642936 Could you please attach the test code you mentioned? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257255&group_id=5470 From noreply at sourceforge.net Thu Aug 25 13:05:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 04:05:04 -0700 Subject: [ python-Bugs-1163178 ] IDNA StreamReader broken Message-ID: Bugs item #1163178, was opened at 2005-03-14 19:38 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163178&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: Unicode Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Martin v. L?wis (loewis) Summary: IDNA StreamReader broken Initial Comment: It seems that the IDNA StreamReader is broken (this problem occurs both in Python 2.3.4 and Python 2.4): >>> import codecs, cStringIO >>> r = codecs.getreader("idna")(cStringIO.StringIO("abc")) >>> r.read(1) u'a' >>> r.read(1) u'b' >>> r.read(1) u'c' >>> r.read(1) u'.' >>> r.read(1) u'.' I would have expected that read(1) returns u"" after the third call. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-25 13:05 Message: Logged In: YES user_id=21627 Thanks for the report. Fixed in idna.py 1.5 test_codecs.py 1.25 NEWS 1.1351 idna.py 1.4.4.1 test_codecs.py 1.15.2.7 NEWS 1.1193.2.85 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163178&group_id=5470 From noreply at sourceforge.net Thu Aug 25 13:24:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 04:24:21 -0700 Subject: [ python-Bugs-1215928 ] Large tarfiles cause overflow Message-ID: Bugs item #1215928, was opened at 2005-06-06 21:19 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&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: Accepted Priority: 5 Submitted By: Tom Emerson (tree) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Large tarfiles cause overflow Initial Comment: I have a 4 gigabyte bz2 compressed tarfile containing some 3.3 million documents. I have a script which opens this file with "r:bz2" and is simply iterating over the contents using next(). With 2.4.1 I still get an Overflow error (originally tried with 2.3.5 as packaged in Mac OS 10.4.1): Traceback (most recent call last): File "extract_part.py", line 47, in ? main(sys.argv) File "extract_part.py", line 39, in main pathnames = find_valid_paths(argv[1], 1024, count) File "extract_part.py", line 13, in find_valid_paths f = tf.next() File "/usr/local/lib/python2.4/tarfile.py", line 1584, in next self.fileobj.seek(self.offset) OverflowError: long int too large to convert to int ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-25 13:24 Message: Logged In: YES user_id=21627 The patch is fine, please apply. As for generalising Py_off_t: there are some issues which I keep forgetting. fpos_t is not guaranteed to be an integral type, and indeed, on Linux, it is not. I'm not quite completely sure why this patch works; I think that on all platforms where fpos_t is not integral, off_t happens to be large enough. The only case where off_t is not large enough is (IIRC) Windows, where fpos_t can be used. So this is all somewhat muddy, and if this gets generalized, a more elaborate comment seems to be in order. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-06-21 01:44 Message: Logged In: YES user_id=142612 The bug has been reproduced with a 90Mbytes bz2 file containing more than 4Gbytes of fairly similar documents. I've diagnosed the same problem with large offsets. Thanks for the patch. Platform: WinXP Intel P4, Python 2.4.1 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-19 00:05 Message: Logged In: YES user_id=80475 Martin, please look at this when you get a chance. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-18 23:26 Message: Logged In: YES user_id=1188172 I looked into this a bit further, and noticed the following: The modules bz2, cStringIO and mmap all use plain integers to represent file offsets given to or returned by seek(), tell() and truncate(). They should be corrected to use a 64-bit type when having large file support. fileobject.c defines an own type for that, Py_off_t, which should be shared among the other modules. Conditional compile is needed since different macros/functions must be used. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-13 03:32 Message: Logged In: YES user_id=80475 Is there a way to write a test for this? Can it be done without a conditional compile? Is the problem one that occurs in other code outside of bz? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-10 13:45 Message: Logged In: YES user_id=1188172 Attaching corrected patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-09 22:31 Message: Logged In: YES user_id=1188172 Attaching a patch which mimics the behaviour of normal file objects. This should resolve the issue on platforms with large file support. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-06-07 15:23 Message: Logged In: YES user_id=642936 A quick look at the problem reveals that this is a bug in bz2.BZ2File. The seek() method does not allow position values >= 2GiB. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 From noreply at sourceforge.net Thu Aug 25 13:31:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 04:31:34 -0700 Subject: [ python-Bugs-990743 ] Crash when importing encoded file Message-ID: Bugs item #990743, was opened at 2004-07-14 11:05 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990743&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: Unicode Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Jurjen N.E. Bos (jneb) Assigned to: Martin v. L?wis (loewis) Summary: Crash when importing encoded file Initial Comment: Python crashes (!) when it meets a non-ascii character in a file with encoding in use. For example: # encoding: mac-roman ... >>> import user #so we can import >>> import foo Parser/tokenizer.c:366: failed assertion `strlen(str) < (size_t)size' Abort When debugging, I found the StreamReader.readline() routine in codecs.py. It self.calls decode, which does return well; then readline returns, and then the inevitable happens. Readline is called straight from the toplevel (from the viewpoint of the debugger), which probably means calling readline is part of the import logic in C. So the bug must somewhere in there... - Jurjen ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-25 13:31 Message: Logged In: YES user_id=21627 Some time has passed, and now I fail to reproduce the problem. It would have helped if you had attached the actual file that causes the bug, and if you had stated the precise Python version and platform on which this bug occurred. So I'm closing this as "works for me". If you can provide further details, and it hasn't been fixed in 2.4, please submit a new report. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-23 12:13 Message: Logged In: YES user_id=38388 Martin, could you have a look at this ? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990743&group_id=5470 From noreply at sourceforge.net Thu Aug 25 13:35:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 04:35:30 -0700 Subject: [ python-Bugs-1269051 ] atexit not called for pythonservice (win32) Message-ID: Bugs item #1269051, was opened at 2005-08-24 22:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1269051&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: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Hari Krishna Dara (haridsv) Assigned to: Nobody/Anonymous (nobody) Summary: atexit not called for pythonservice (win32) Initial Comment: I have a couple of functions registered with atexit which work fine when the program is executed on command-line. But when I run the same as a windows service, and stop the service using service interface, these hooks never get call backs. The service does exit normally (at least my program doesn't do os._exit() and there are no exceptions). I am using ActiveState's distribution of python, but I would imagine this is non-specific. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-25 13:35 Message: Logged In: YES user_id=21627 Well, it is specific in the sense that the Windows service integration is not part of the standard Python distribution. So I recommend to report this to pythonwin: https://sourceforge.net/projects/pywin32/ Closing this report as third-party. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1269051&group_id=5470 From noreply at sourceforge.net Thu Aug 25 15:11:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 06:11:17 -0700 Subject: [ python-Bugs-1215928 ] Large tarfiles cause overflow Message-ID: Bugs item #1215928, was opened at 2005-06-06 21:19 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Tom Emerson (tree) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Large tarfiles cause overflow Initial Comment: I have a 4 gigabyte bz2 compressed tarfile containing some 3.3 million documents. I have a script which opens this file with "r:bz2" and is simply iterating over the contents using next(). With 2.4.1 I still get an Overflow error (originally tried with 2.3.5 as packaged in Mac OS 10.4.1): Traceback (most recent call last): File "extract_part.py", line 47, in ? main(sys.argv) File "extract_part.py", line 39, in main pathnames = find_valid_paths(argv[1], 1024, count) File "extract_part.py", line 13, in find_valid_paths f = tf.next() File "/usr/local/lib/python2.4/tarfile.py", line 1584, in next self.fileobj.seek(self.offset) OverflowError: long int too large to convert to int ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 15:11 Message: Logged In: YES user_id=1188172 I just realized that I accidentally committed the patch together with the fix for #1191043. Modules/bz2module r1.25, r1.23.2.2. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-25 13:24 Message: Logged In: YES user_id=21627 The patch is fine, please apply. As for generalising Py_off_t: there are some issues which I keep forgetting. fpos_t is not guaranteed to be an integral type, and indeed, on Linux, it is not. I'm not quite completely sure why this patch works; I think that on all platforms where fpos_t is not integral, off_t happens to be large enough. The only case where off_t is not large enough is (IIRC) Windows, where fpos_t can be used. So this is all somewhat muddy, and if this gets generalized, a more elaborate comment seems to be in order. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-06-21 01:44 Message: Logged In: YES user_id=142612 The bug has been reproduced with a 90Mbytes bz2 file containing more than 4Gbytes of fairly similar documents. I've diagnosed the same problem with large offsets. Thanks for the patch. Platform: WinXP Intel P4, Python 2.4.1 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-19 00:05 Message: Logged In: YES user_id=80475 Martin, please look at this when you get a chance. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-18 23:26 Message: Logged In: YES user_id=1188172 I looked into this a bit further, and noticed the following: The modules bz2, cStringIO and mmap all use plain integers to represent file offsets given to or returned by seek(), tell() and truncate(). They should be corrected to use a 64-bit type when having large file support. fileobject.c defines an own type for that, Py_off_t, which should be shared among the other modules. Conditional compile is needed since different macros/functions must be used. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-13 03:32 Message: Logged In: YES user_id=80475 Is there a way to write a test for this? Can it be done without a conditional compile? Is the problem one that occurs in other code outside of bz? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-10 13:45 Message: Logged In: YES user_id=1188172 Attaching corrected patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-09 22:31 Message: Logged In: YES user_id=1188172 Attaching a patch which mimics the behaviour of normal file objects. This should resolve the issue on platforms with large file support. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-06-07 15:23 Message: Logged In: YES user_id=642936 A quick look at the problem reveals that this is a bug in bz2.BZ2File. The seek() method does not allow position values >= 2GiB. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470 From noreply at sourceforge.net Thu Aug 25 15:20:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 06:20:35 -0700 Subject: [ python-Bugs-1119418 ] xrange() builtin accepts keyword arg silently Message-ID: Bugs item #1119418, was opened at 2005-02-09 17:57 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&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: None Status: Open Resolution: None Priority: 6 Submitted By: Martin Blais (blais) >Assigned to: Raymond Hettinger (rhettinger) Summary: xrange() builtin accepts keyword arg silently Initial Comment: Calling ``xrange(10, 100, step=10)`` results in a xrange(10, 100) iterator silently. In contrast, ``range(10, 100, step=10)`` raises an exception. See test program below. Two possible fixes: 1. fix xrange() so that it returns a xrange(10, 100, 10) iterator 2. make sure that xrange() raises an exception too. #!/usr/bin/env python def foo( min_, max_, step=1 ): print min_, max_, step print '====================' foo(10, 100, 10) foo(10, 100, step=10) print '====================' print xrange(10, 100, 10) print xrange(10, 100, step=10) print '====================' print range(10, 100, 10) print range(10, 100, step=10) elbow:/usr/.../lib/python2.4$ /tmp/a.py ==================== 10 100 10 10 100 10 ==================== xrange(10, 100, 10) xrange(10, 100) ==================== [10, 20, 30, 40, 50, 60, 70, 80, 90] Traceback (most recent call last): File "/tmp/a.py", line 16, in ? print range(10, 100, step=10) TypeError: range() takes no keyword arguments > /tmp/a.py(16)?() -> print range(10, 100, step=10) (Pdb) elbow:/usr/.../lib/python2.4$ ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 15:20 Message: Logged In: YES user_id=1188172 Please review. Should I work on a patch to buffer, set and slice, too? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-09 23:04 Message: Logged In: YES user_id=1188172 I delved deeper into this, and it seems that the difference is caused by range being a method (of bltinmodule, defined as METH_VARARGS), while xrange is a constructor for a rangeobject. Such constructor functions get three arguments (the type object, the args and the kw args), and when the kw args are not checked like in str(), they can pass freely and are ignored. I have attached a patch which changes the range object constructor (xrange) to accept keyword arguments. Other builtin types that need such a correction include buffer, set, slice. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 23:21 Message: Logged In: YES user_id=593130 Functions coded in C generally do not take keyword arguments. (Special coding is required to achieve otherwise.) In 2.2, range and xrange both followed this rule: >>> xrange(1,20,step=2) Traceback (most recent call last): File "", line 1, in ? TypeError: xrange() takes no keyword arguments >>> range(1,20,step=2) Traceback (most recent call last): File "", line 1, in ? TypeError: range() takes no keyword arguments So, removal of the error message by 2.4 seem to be a bug. Surprise: >>> str(object=1) '1' >>> str(i=2) Traceback (most recent call last): File "", line 1, in ? TypeError: 'i' is an invalid keyword argument for this function There is nothing in the doc(Lib Ref) or doc string of str vs. range and xrange that would lead me to expect this. I looked around CVS a bit to see if the past or possible future change was something simple, but I could not find source of error message in bltinmodule.c, ceval.c, getargs.c, rangeobject.c, or typeobject.c, so I will leave this to someone else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&group_id=5470 From noreply at sourceforge.net Thu Aug 25 15:22:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 06:22:28 -0700 Subject: [ python-Bugs-754016 ] urlparse goes wrong with IP:port without scheme Message-ID: Bugs item #754016, was opened at 2003-06-13 17:15 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754016&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Kr?ger (kruegi) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: urlparse goes wrong with IP:port without scheme Initial Comment: urlparse doesnt work if IP and port are given without scheme: >>> urlparse.urlparse('1.2.3.4:80','http') ('1.2.3.4', '', '80', '', '', '') should be: >>> urlparse.urlparse('1.2.3.4:80','http') ('http', '1.2.3.4', '80', '', '', '') ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 15:22 Message: Logged In: YES user_id=1188172 Will look into it. Should be easy to fix. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 22:55 Message: Logged In: YES user_id=752496 The problem is still present in Py2.3.4. IMO, it should support dirs without the "http://" or raise an error if it's not present (never fail silently!). ---------------------------------------------------------------------- Comment By: Shannon Jones (sjones) Date: 2003-06-14 06:18 Message: Logged In: YES user_id=589306 Ok, I researched this a bit, and the situation isn't as simple as it first appears. The RFC that urlparse tries to follow is at http://www.faqs.org/rfcs/rfc1808.html and notice specifically sections 2.1 and 2.2. It seems to me that the source code follows rfc1808 religiously, and in that sense it does the correct thing. According to the RFC, the netloc should begin with a '//', and since your example didn't include one then it technical was an invalid URL. Here is another example where it seems Python fails to do the right thing: >>> urlparse.urlparse('python.org') ('', '', 'python.org', '', '', '') >>> urlparse.urlparse('python.org', 'http') ('http', '', 'python.org', '', '', '') Note that it is putting 'python.org' as the path and not the netloc. So the problem isn't limited to just when you use a scheme parameter and/or a port number. Now if we put '//' at the beginning, we get: >>> urlparse.urlparse('//python.org') ('', 'python.org', '', '', '', '') >>> urlparse.urlparse('//python.org', 'http') ('http', 'python.org', '', '', '', '') So here it does the correct thing. There are two problems though. First, it is common for browsers and other software to just take a URL without a scheme and '://' and assume it is http for the user. While the URL is technically not correct, it is still common usage. Also, urlparse does take a scheme parameter. It seems as though this parameter should be used with a scheme-less URL to give it a default one like web browsers do. So somebody needs to make a decision. Should urlparse follow the RFC religiously and require '//' in front of netlocs? If so, I think the documentation should give an example showing this and showing how to use the 'scheme' parameter. Or should urlparse use the more commonly used form of a URL where '//' is omitted when the scheme is omitted? If so, urlparse.py will need to be changed. Or maybe another fuction should be added to cover whichever behaviour urlparse doesn't cover. In any case, you can temporarily solve your problem by making sure that URL's without a scheme have '//' at the front. So your example becomes: >>> urlparse.urlparse('//1.2.3.4:80', 'http') ('http', '1.2.3.4:80', '', '', '', '') ---------------------------------------------------------------------- Comment By: Shannon Jones (sjones) Date: 2003-06-14 04:39 Message: Logged In: YES user_id=589306 Sorry, previous comment got cut off... urlparse.urlparse takes a url of the format: <scheme>://<netloc>/<path>;<params>?<query>#<fragment> And returns a 6-tuple of the format: (scheme, netloc, path, params, query, fragment). An example from the library refrence takes: urlparse('http://www.cwi.nl:80/%7Eguido/Python.html') And produces: ('http', 'www.cwi.nl:80', '/%7Eguido/Python.html', '', '', '') -------------------------------- Note that there isn't a field for the port number in the 6-tuple. Instead, it is included in the netloc. Urlparse should handle your example as: >>> urlparse.urlparse('1.2.3.4:80','http') ('http', '1.2.3.4:80', '', '', '', '') Instead, it gives the incorrect output as you indicated. ---------------------------------------------------------------------- Comment By: Shannon Jones (sjones) Date: 2003-06-14 04:26 Message: Logged In: YES user_id=589306 urlparse.urlparse takes a url of the format: <scheme>://<netloc>/<path>;<params>?<query>#<fragment> And returns a 6-tuple of the format: (scheme, netloc, path, params, query, fragment). An example from the library refrence takes: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754016&group_id=5470 From noreply at sourceforge.net Thu Aug 25 15:28:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 06:28:31 -0700 Subject: [ python-Bugs-864374 ] 2.3.3 tests on cygwin Message-ID: Bugs item #864374, was opened at 2003-12-22 12:30 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864374&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.3 tests on cygwin Initial Comment: Hello, After running ./configure --prefix=/usr make make test I get the following --- 217 tests OK. 7 tests failed: test_bz2 test_fork1 test_largefile test_os test_popen2 test_pty test_tempfile 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_dbm test_email_codecs test_gl test_imgfile test_ioctl test_linuxaudiodev test_locale test_macfs test_macostools test_mpz test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound Those skips are all expected on cygwin. When running test_bz2, test_fork1, test_popen2, test_pty, test_tempfile alone they look ok (return value to OS is 0). For the others I'm attaching output. My system is win2k on IBM T30 (laptop). Cygwin 1.5.5. Miki ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 15:28 Message: Logged In: YES user_id=1188172 Can you verify this with 2.4.1 or a CVS version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864374&group_id=5470 From noreply at sourceforge.net Thu Aug 25 16:35:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 07:35:12 -0700 Subject: [ python-Bugs-1119418 ] xrange() builtin accepts keyword arg silently Message-ID: Bugs item #1119418, was opened at 2005-02-09 11:57 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&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: None Status: Open Resolution: None Priority: 6 Submitted By: Martin Blais (blais) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: xrange() builtin accepts keyword arg silently Initial Comment: Calling ``xrange(10, 100, step=10)`` results in a xrange(10, 100) iterator silently. In contrast, ``range(10, 100, step=10)`` raises an exception. See test program below. Two possible fixes: 1. fix xrange() so that it returns a xrange(10, 100, 10) iterator 2. make sure that xrange() raises an exception too. #!/usr/bin/env python def foo( min_, max_, step=1 ): print min_, max_, step print '====================' foo(10, 100, 10) foo(10, 100, step=10) print '====================' print xrange(10, 100, 10) print xrange(10, 100, step=10) print '====================' print range(10, 100, 10) print range(10, 100, step=10) elbow:/usr/.../lib/python2.4$ /tmp/a.py ==================== 10 100 10 10 100 10 ==================== xrange(10, 100, 10) xrange(10, 100) ==================== [10, 20, 30, 40, 50, 60, 70, 80, 90] Traceback (most recent call last): File "/tmp/a.py", line 16, in ? print range(10, 100, step=10) TypeError: range() takes no keyword arguments > /tmp/a.py(16)?() -> print range(10, 100, step=10) (Pdb) elbow:/usr/.../lib/python2.4$ ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-25 09:35 Message: Logged In: YES user_id=80475 xrange() needs to be kept closely parallel with range() . Accordingly, it should not sprout keyword arguments. For all of these, I think the solution is to raise a TypeError when keyword arguments are supplied to functions/types that don't handle them. Encapsulate the logic in a new internal API function: int _PyArg_NoKeywords(char *funcname, PyObject *kwds) { if (kwds == NULL) return 1; if (!PyDict_CheckExact(kwds)){ bad internal call return 0; } if (PyDict_Size(kwds) == 0) return 1; set_exc_typeerror(funcname does not take kw args) return 0; } Then go through the code finding all the type constructors (grep for PyTypeObject) and add the error check if the kwds arg is being ignored). For example: range_new(PyTypeObject *type, PyObject *args, PyObject *kw) { if (!_PyArg_NoKeywords("xrange", kw)) return NULL; . . . Be sure to add test cases for every constructor that gets changed. Also, go ahead an backport to Py2.4.2. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 08:20 Message: Logged In: YES user_id=1188172 Please review. Should I work on a patch to buffer, set and slice, too? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-09 16:04 Message: Logged In: YES user_id=1188172 I delved deeper into this, and it seems that the difference is caused by range being a method (of bltinmodule, defined as METH_VARARGS), while xrange is a constructor for a rangeobject. Such constructor functions get three arguments (the type object, the args and the kw args), and when the kw args are not checked like in str(), they can pass freely and are ignored. I have attached a patch which changes the range object constructor (xrange) to accept keyword arguments. Other builtin types that need such a correction include buffer, set, slice. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 17:21 Message: Logged In: YES user_id=593130 Functions coded in C generally do not take keyword arguments. (Special coding is required to achieve otherwise.) In 2.2, range and xrange both followed this rule: >>> xrange(1,20,step=2) Traceback (most recent call last): File "", line 1, in ? TypeError: xrange() takes no keyword arguments >>> range(1,20,step=2) Traceback (most recent call last): File "", line 1, in ? TypeError: range() takes no keyword arguments So, removal of the error message by 2.4 seem to be a bug. Surprise: >>> str(object=1) '1' >>> str(i=2) Traceback (most recent call last): File "", line 1, in ? TypeError: 'i' is an invalid keyword argument for this function There is nothing in the doc(Lib Ref) or doc string of str vs. range and xrange that would lead me to expect this. I looked around CVS a bit to see if the past or possible future change was something simple, but I could not find source of error message in bltinmodule.c, ceval.c, getargs.c, rangeobject.c, or typeobject.c, so I will leave this to someone else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&group_id=5470 From noreply at sourceforge.net Thu Aug 25 22:21:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 13:21:08 -0700 Subject: [ python-Bugs-1119418 ] xrange() builtin accepts keyword arg silently Message-ID: Bugs item #1119418, was opened at 2005-02-09 17:57 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&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: None Status: Open Resolution: None Priority: 6 Submitted By: Martin Blais (blais) >Assigned to: Raymond Hettinger (rhettinger) Summary: xrange() builtin accepts keyword arg silently Initial Comment: Calling ``xrange(10, 100, step=10)`` results in a xrange(10, 100) iterator silently. In contrast, ``range(10, 100, step=10)`` raises an exception. See test program below. Two possible fixes: 1. fix xrange() so that it returns a xrange(10, 100, 10) iterator 2. make sure that xrange() raises an exception too. #!/usr/bin/env python def foo( min_, max_, step=1 ): print min_, max_, step print '====================' foo(10, 100, 10) foo(10, 100, step=10) print '====================' print xrange(10, 100, 10) print xrange(10, 100, step=10) print '====================' print range(10, 100, 10) print range(10, 100, step=10) elbow:/usr/.../lib/python2.4$ /tmp/a.py ==================== 10 100 10 10 100 10 ==================== xrange(10, 100, 10) xrange(10, 100) ==================== [10, 20, 30, 40, 50, 60, 70, 80, 90] Traceback (most recent call last): File "/tmp/a.py", line 16, in ? print range(10, 100, step=10) TypeError: range() takes no keyword arguments > /tmp/a.py(16)?() -> print range(10, 100, step=10) (Pdb) elbow:/usr/.../lib/python2.4$ ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 22:21 Message: Logged In: YES user_id=1188172 Attaching a huge patch. It introduces the function you described, and calls it in the constructors of xrange, set, frozenset, buffer and slice. Moreover, I found it to be necessary in objects in the following modules: - array (array) - itertools (cycle, dropwhile, takewhile, islice, imap, chain, ifilter, count, izip, repeat) - operator (attrgetter, itemgetter) - _random (Random) - zipimport (zipimporter) - collections (deque) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-25 16:35 Message: Logged In: YES user_id=80475 xrange() needs to be kept closely parallel with range() . Accordingly, it should not sprout keyword arguments. For all of these, I think the solution is to raise a TypeError when keyword arguments are supplied to functions/types that don't handle them. Encapsulate the logic in a new internal API function: int _PyArg_NoKeywords(char *funcname, PyObject *kwds) { if (kwds == NULL) return 1; if (!PyDict_CheckExact(kwds)){ bad internal call return 0; } if (PyDict_Size(kwds) == 0) return 1; set_exc_typeerror(funcname does not take kw args) return 0; } Then go through the code finding all the type constructors (grep for PyTypeObject) and add the error check if the kwds arg is being ignored). For example: range_new(PyTypeObject *type, PyObject *args, PyObject *kw) { if (!_PyArg_NoKeywords("xrange", kw)) return NULL; . . . Be sure to add test cases for every constructor that gets changed. Also, go ahead an backport to Py2.4.2. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 15:20 Message: Logged In: YES user_id=1188172 Please review. Should I work on a patch to buffer, set and slice, too? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-09 23:04 Message: Logged In: YES user_id=1188172 I delved deeper into this, and it seems that the difference is caused by range being a method (of bltinmodule, defined as METH_VARARGS), while xrange is a constructor for a rangeobject. Such constructor functions get three arguments (the type object, the args and the kw args), and when the kw args are not checked like in str(), they can pass freely and are ignored. I have attached a patch which changes the range object constructor (xrange) to accept keyword arguments. Other builtin types that need such a correction include buffer, set, slice. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 23:21 Message: Logged In: YES user_id=593130 Functions coded in C generally do not take keyword arguments. (Special coding is required to achieve otherwise.) In 2.2, range and xrange both followed this rule: >>> xrange(1,20,step=2) Traceback (most recent call last): File "", line 1, in ? TypeError: xrange() takes no keyword arguments >>> range(1,20,step=2) Traceback (most recent call last): File "", line 1, in ? TypeError: range() takes no keyword arguments So, removal of the error message by 2.4 seem to be a bug. Surprise: >>> str(object=1) '1' >>> str(i=2) Traceback (most recent call last): File "", line 1, in ? TypeError: 'i' is an invalid keyword argument for this function There is nothing in the doc(Lib Ref) or doc string of str vs. range and xrange that would lead me to expect this. I looked around CVS a bit to see if the past or possible future change was something simple, but I could not find source of error message in bltinmodule.c, ceval.c, getargs.c, rangeobject.c, or typeobject.c, so I will leave this to someone else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&group_id=5470 From noreply at sourceforge.net Thu Aug 25 23:45:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 14:45:10 -0700 Subject: [ python-Bugs-1243553 ] pydoc on cgi.escape lacks info that are in www docs Message-ID: Bugs item #1243553, was opened at 2005-07-23 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=1243553&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: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nikos Kouremenos (nkour) Assigned to: Skip Montanaro (montanaro) Summary: pydoc on cgi.escape lacks info that are in www docs Initial Comment: WWW: escape( s[, quote]) Convert the characters "&", "<" and ">" in string s to HTML-safe sequences. Use this if you need to display text that might contain such characters in HTML. If the optional flag quote is true, the double-quote character (""") is also translated; this helps for inclusion in an HTML attribute value, as in . If the value to be quoted might include single- or double-quote characters, or both, consider using the quoteattr() function in the xml.sax.saxutils module instead. pydoc cgi.escape = escape(s, quote=None) Replace special characters '&', '<' and '>' by SGML entities. why? ;( moreover pydoc doesn't even say what quote is!! ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 23:45 Message: Logged In: YES user_id=1188172 Closing, then. To the OP: If you have any more instances where the docstring misses crucial information, please open a new report. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-08-02 04:54 Message: Logged In: YES user_id=44345 I expanded the cgi.escape docstring a bit (v 1.84). In general though, the online doc can't really be a complete substitute for the reference documentation. It should be treated more as a hint for usage. ---------------------------------------------------------------------- Comment By: Nikos Kouremenos (nkour) Date: 2005-07-24 15:20 Message: Logged In: YES user_id=865368 pterk, thank you ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-24 14:55 Message: Logged In: YES user_id=174455 The documentation from pydoc is generated from doc-strings in the python source. Not only does this limit what you can do with it (hence the need for more elaborate documentation), it is also reasonable that this documentation remains terse. You should consider it more as a quick reference in stead of full-on documentation. I have submitted a small patch (1243910) to include a comment in the doc-string about quote. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243553&group_id=5470 From noreply at sourceforge.net Thu Aug 25 23:46:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 14:46:40 -0700 Subject: [ python-Bugs-1247765 ] "new" not marked as deprecated in the docs Message-ID: Bugs item #1247765, was opened at 2005-07-30 01:37 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1247765&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: None >Status: Closed >Resolution: Later Priority: 5 Submitted By: J?rgen Hermann (jhermann) Assigned to: Nobody/Anonymous (nobody) Summary: "new" not marked as deprecated in the docs Initial Comment: While >>> help('new') shows the deprecation of this module starting with 2.3, the docs at http://www.python.org/doc/current/lib/module-new.html don't. Shouldn't they? ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 23:46 Message: Logged In: YES user_id=1188172 I think that nothing will happen here before 3.0. Both modules are used too heavily to be deprecated. ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-08-03 11:12 Message: Logged In: YES user_id=987664 When searching Python-dev all I could find was discussion over the eventual deprecation of types. If you deprecate the types module you still need a way to access the five types exposed in new. new is not listed in PEP 4 (Deprecation of Standard Modules). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-03 10:51 Message: Logged In: YES user_id=1188172 Shouldn't it be deprecated? Look at the code in new.py. The only thing I can say in favour of new is that new.instancemethod() is prettier and clearer than types.MethodType(). ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-08-03 10:16 Message: Logged In: YES user_id=987664 The new module should not be deprecated yet; it is help("new") that should be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1247765&group_id=5470 From noreply at sourceforge.net Thu Aug 25 23:48:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 14:48:17 -0700 Subject: [ python-Bugs-1243945 ] Python function/method/constant names as HTML-tag IDs Message-ID: Bugs item #1243945, was opened at 2005-07-24 17:19 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243945&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: Chad Miller (chadmiller) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Python function/method/constant names as HTML-tag IDs Initial Comment: It would be very nice if HTML tag IDs were predictable, and not generated. For instance, when newbie-Joe complains on IRC about his program, I'd much rather be able to point him to http://python.org/doc/current/lib/built-in-funcs#input instead of http://python.org/doc/current/lib/built-in-funcs#l2h-38 or telling him to find it manually. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 23:48 Message: Logged In: YES user_id=1188172 And the Tutorial section anchors aren't very pretty, too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243945&group_id=5470 From noreply at sourceforge.net Thu Aug 25 23:57:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 14:57:04 -0700 Subject: [ python-Bugs-1261229 ] __new__ is class method Message-ID: Bugs item #1261229, was opened at 2005-08-16 20:53 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261229&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mike Orr (hierro) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: __new__ is class method Initial Comment: Section 3.3.1 of the Language Reference says, " __new__() is a static method" But it's actually a class method since it's first argument is the class. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 23:57 Message: Logged In: YES user_id=1188172 Thanks for the report, fixed in Doc/ref/ref3.tex r1.127, 1.121.2.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261229&group_id=5470 From noreply at sourceforge.net Fri Aug 26 00:14:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 15:14:29 -0700 Subject: [ python-Bugs-1262320 ] minidom.py alternate newl support is broken Message-ID: Bugs item #1262320, was opened at 2005-08-17 19:11 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1262320&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: XML Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Whitley (jwhitley) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: minidom.py alternate newl support is broken Initial Comment: In minidom.py, class Document and a few other nodes have hardcoded newlines ('\n') remaining, causing the "newl" parameter to potentially produce a file with mixed line endings, e.g. if newl is set to Windows line endings ("\r\n" ). A diff follows which fixes all instances of the problem of which I'm aware. *** /usr/lib/python2.4/xml/dom/minidom.py.orig Tue Aug 16 17:38:40 2005 --- /usr/lib/python2.4/xml/dom/minidom.py.new Tue Aug 16 17:38:40 2005 *************** *** 1286,1292 **** writer.write(" [") writer.write(self.internalSubset) writer.write("]") ! writer.write(">\n") class Entity(Identified, Node): attributes = None --- 1286,1292 ---- writer.write(" [") writer.write(self.internalSubset) writer.write("]") ! writer.write(">%s" % newl) class Entity(Identified, Node): attributes = None *************** *** 1739,1747 **** def writexml(self, writer, indent="", addindent="", newl="", encoding = None): if encoding is None: ! writer.write('\n') else: ! writer.write('\n' % encoding) for node in self.childNodes: node.writexml(writer, indent, addindent, newl) --- 1739,1747 ---- def writexml(self, writer, indent="", addindent="", newl="", encoding = None): if encoding is None: ! writer.write('%s' % newl) else: ! writer.write('%s' % (encoding,newl)) for node in self.childNodes: node.writexml(writer, indent, addindent, newl) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 00:14 Message: Logged In: YES user_id=1188172 Thanks for the report, fixed in Lib/xml/dom/minidom.py r1.53, 1.52.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1262320&group_id=5470 From noreply at sourceforge.net Fri Aug 26 00:20:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 15:20:13 -0700 Subject: [ python-Bugs-1273504 ] Cycle containing a Set is not GC'd [leak] Message-ID: Bugs item #1273504, was opened at 2005-08-25 22:20 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=1273504&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: Pierre-Fr?d?ric Caillaud (peufeu) Assigned to: Nobody/Anonymous (nobody) Summary: Cycle containing a Set is not GC'd [leak] Initial Comment: Summary ------------------------- Python's GC detects cycles except if there is a set somewhere in the cycle. For instance. >>> class Survivor( object ): ... def __init__( self ): ... self.s = set( (self,) ) ... >>> Survivor() <__main__.Survivor object at 0xb7ce68ac> >>> Survivor() <__main__.Survivor object at 0xb79b0b0c> >>> len( [ x for x in gc.get_objects() if isinstance( x, Survivor ) ] ) 2 >>> gc.collect() 0 >>> gc.collect() 0 >>> len( [ x for x in gc.get_objects() if isinstance( x, Survivor ) ] ) 2 >>> [ x for x in gc.get_objects() if isinstance( x, Survivor ) ] [<__main__.Survivor object at 0xb7ce68ac>, <__main__.Survivor object at 0xb79b0b0c>] So, the Survivors survive gc.collect() ! See more complete test case below. System infos ------------------------- $ python Python 2.4.1 (#1, May 14 2005, 18:44:52) [GCC 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)] on linux2 >>> import gc >>> gc.get_threshold() (700, 10, 10) OK, gc is compiled in, proceed... Test Case ------------------------- The attached program creates a new-style class and an old-style class (of appropriate names). We create instances of these objects, each having only a member, being a set, or a dict, or a list. Then we create a cycle by putting the object itself inside this list, dict, or set, collect() a few times ; cycles involving lists and dicts are gone, cycles involving sets stay. This was to check if it had anything to do with something else than sets ; apparently sets are the cause. The source is self-explanatory. Enjoy ! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1273504&group_id=5470 From noreply at sourceforge.net Fri Aug 26 00:25:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 15:25:48 -0700 Subject: [ python-Bugs-1273504 ] Cycle containing a Set is not GC'd [leak] Message-ID: Bugs item #1273504, was opened at 2005-08-25 18:20 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1273504&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: Pierre-Fr?d?ric Caillaud (peufeu) >Assigned to: Raymond Hettinger (rhettinger) Summary: Cycle containing a Set is not GC'd [leak] Initial Comment: Summary ------------------------- Python's GC detects cycles except if there is a set somewhere in the cycle. For instance. >>> class Survivor( object ): ... def __init__( self ): ... self.s = set( (self,) ) ... >>> Survivor() <__main__.Survivor object at 0xb7ce68ac> >>> Survivor() <__main__.Survivor object at 0xb79b0b0c> >>> len( [ x for x in gc.get_objects() if isinstance( x, Survivor ) ] ) 2 >>> gc.collect() 0 >>> gc.collect() 0 >>> len( [ x for x in gc.get_objects() if isinstance( x, Survivor ) ] ) 2 >>> [ x for x in gc.get_objects() if isinstance( x, Survivor ) ] [<__main__.Survivor object at 0xb7ce68ac>, <__main__.Survivor object at 0xb79b0b0c>] So, the Survivors survive gc.collect() ! See more complete test case below. System infos ------------------------- $ python Python 2.4.1 (#1, May 14 2005, 18:44:52) [GCC 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)] on linux2 >>> import gc >>> gc.get_threshold() (700, 10, 10) OK, gc is compiled in, proceed... Test Case ------------------------- The attached program creates a new-style class and an old-style class (of appropriate names). We create instances of these objects, each having only a member, being a set, or a dict, or a list. Then we create a cycle by putting the object itself inside this list, dict, or set, collect() a few times ; cycles involving lists and dicts are gone, cycles involving sets stay. This was to check if it had anything to do with something else than sets ; apparently sets are the cause. The source is self-explanatory. Enjoy ! ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-08-25 18:25 Message: Logged In: YES user_id=31435 Assigned to Raymond. Is this a duplicate of http://www.python.org/sf/1200018 ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1273504&group_id=5470 From noreply at sourceforge.net Fri Aug 26 00:40:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 15:40:48 -0700 Subject: [ python-Bugs-1248199 ] shelve .sync operation not documented Message-ID: Bugs item #1248199, was opened at 2005-07-31 04:53 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248199&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: Closed >Resolution: Fixed Priority: 5 Submitted By: paul rubin (phr) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: shelve .sync operation not documented Initial Comment: The shelve documentation doesn't describe how to flush updates out to the disc file. Without that, a long-running server could go for months without writing out any updates. A server crash would then lose every update. I asked on clpy whether shelve really had such a severe deficiency. Thanks to Robert Kern for mentioning the .sync() method, which does what is needed. The doc should definitely mention this. Shelve is much less useful without it. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 00:40 Message: Logged In: YES user_id=1188172 Thanks for the report, fixed in Doc/lib/libshelve.py r1.23, 1.20.16.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248199&group_id=5470 From noreply at sourceforge.net Fri Aug 26 01:09:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 16:09:42 -0700 Subject: [ python-Bugs-1273504 ] Cycle containing a Set is not GC'd [leak] Message-ID: Bugs item #1273504, was opened at 2005-08-25 22:20 Message generated for change (Comment added) made by peufeu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1273504&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: Pierre-Fr?d?ric Caillaud (peufeu) Assigned to: Raymond Hettinger (rhettinger) Summary: Cycle containing a Set is not GC'd [leak] Initial Comment: Summary ------------------------- Python's GC detects cycles except if there is a set somewhere in the cycle. For instance. >>> class Survivor( object ): ... def __init__( self ): ... self.s = set( (self,) ) ... >>> Survivor() <__main__.Survivor object at 0xb7ce68ac> >>> Survivor() <__main__.Survivor object at 0xb79b0b0c> >>> len( [ x for x in gc.get_objects() if isinstance( x, Survivor ) ] ) 2 >>> gc.collect() 0 >>> gc.collect() 0 >>> len( [ x for x in gc.get_objects() if isinstance( x, Survivor ) ] ) 2 >>> [ x for x in gc.get_objects() if isinstance( x, Survivor ) ] [<__main__.Survivor object at 0xb7ce68ac>, <__main__.Survivor object at 0xb79b0b0c>] So, the Survivors survive gc.collect() ! See more complete test case below. System infos ------------------------- $ python Python 2.4.1 (#1, May 14 2005, 18:44:52) [GCC 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)] on linux2 >>> import gc >>> gc.get_threshold() (700, 10, 10) OK, gc is compiled in, proceed... Test Case ------------------------- The attached program creates a new-style class and an old-style class (of appropriate names). We create instances of these objects, each having only a member, being a set, or a dict, or a list. Then we create a cycle by putting the object itself inside this list, dict, or set, collect() a few times ; cycles involving lists and dicts are gone, cycles involving sets stay. This was to check if it had anything to do with something else than sets ; apparently sets are the cause. The source is self-explanatory. Enjoy ! ---------------------------------------------------------------------- >Comment By: Pierre-Fr?d?ric Caillaud (peufeu) Date: 2005-08-25 23:09 Message: Logged In: YES user_id=587274 Looks like it's a dupe. I did not see it in the release notes. Is it fixed in a recently released version ? It's a rather annoying bug, caught a server process hogging all the RAM and swap today because of this one. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-08-25 22:25 Message: Logged In: YES user_id=31435 Assigned to Raymond. Is this a duplicate of http://www.python.org/sf/1200018 ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1273504&group_id=5470 From noreply at sourceforge.net Fri Aug 26 03:53:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 18:53:20 -0700 Subject: [ python-Bugs-1269051 ] atexit not called for pythonservice (win32) Message-ID: Bugs item #1269051, was opened at 2005-08-24 13:05 Message generated for change (Comment added) made by haridsv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1269051&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: 3rd Party Status: Closed Resolution: Invalid Priority: 5 Submitted By: Hari Krishna Dara (haridsv) Assigned to: Nobody/Anonymous (nobody) Summary: atexit not called for pythonservice (win32) Initial Comment: I have a couple of functions registered with atexit which work fine when the program is executed on command-line. But when I run the same as a windows service, and stop the service using service interface, these hooks never get call backs. The service does exit normally (at least my program doesn't do os._exit() and there are no exceptions). I am using ActiveState's distribution of python, but I would imagine this is non-specific. ---------------------------------------------------------------------- >Comment By: Hari Krishna Dara (haridsv) Date: 2005-08-25 18:53 Message: Logged In: YES user_id=344432 Thanks for pointing it out. I have logged an issue at: https://sourceforge.net/tracker/index.php?func=detail&aid=1273738&group_id=78018&atid=551954 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-25 04:35 Message: Logged In: YES user_id=21627 Well, it is specific in the sense that the Windows service integration is not part of the standard Python distribution. So I recommend to report this to pythonwin: https://sourceforge.net/projects/pywin32/ Closing this report as third-party. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1269051&group_id=5470 From noreply at sourceforge.net Fri Aug 26 05:53:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 20:53:36 -0700 Subject: [ python-Bugs-1273504 ] Cycle containing a Set is not GC'd [leak] Message-ID: Bugs item #1273504, was opened at 2005-08-25 17:20 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1273504&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: Closed >Resolution: Duplicate Priority: 5 Submitted By: Pierre-Fr?d?ric Caillaud (peufeu) Assigned to: Raymond Hettinger (rhettinger) Summary: Cycle containing a Set is not GC'd [leak] Initial Comment: Summary ------------------------- Python's GC detects cycles except if there is a set somewhere in the cycle. For instance. >>> class Survivor( object ): ... def __init__( self ): ... self.s = set( (self,) ) ... >>> Survivor() <__main__.Survivor object at 0xb7ce68ac> >>> Survivor() <__main__.Survivor object at 0xb79b0b0c> >>> len( [ x for x in gc.get_objects() if isinstance( x, Survivor ) ] ) 2 >>> gc.collect() 0 >>> gc.collect() 0 >>> len( [ x for x in gc.get_objects() if isinstance( x, Survivor ) ] ) 2 >>> [ x for x in gc.get_objects() if isinstance( x, Survivor ) ] [<__main__.Survivor object at 0xb7ce68ac>, <__main__.Survivor object at 0xb79b0b0c>] So, the Survivors survive gc.collect() ! See more complete test case below. System infos ------------------------- $ python Python 2.4.1 (#1, May 14 2005, 18:44:52) [GCC 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)] on linux2 >>> import gc >>> gc.get_threshold() (700, 10, 10) OK, gc is compiled in, proceed... Test Case ------------------------- The attached program creates a new-style class and an old-style class (of appropriate names). We create instances of these objects, each having only a member, being a set, or a dict, or a list. Then we create a cycle by putting the object itself inside this list, dict, or set, collect() a few times ; cycles involving lists and dicts are gone, cycles involving sets stay. This was to check if it had anything to do with something else than sets ; apparently sets are the cause. The source is self-explanatory. Enjoy ! ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-25 22:53 Message: Logged In: YES user_id=80475 This is a duplicate report. Was fixed for 2.4.2. which should be out in September. ---------------------------------------------------------------------- Comment By: Pierre-Fr?d?ric Caillaud (peufeu) Date: 2005-08-25 18:09 Message: Logged In: YES user_id=587274 Looks like it's a dupe. I did not see it in the release notes. Is it fixed in a recently released version ? It's a rather annoying bug, caught a server process hogging all the RAM and swap today because of this one. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-08-25 17:25 Message: Logged In: YES user_id=31435 Assigned to Raymond. Is this a duplicate of http://www.python.org/sf/1200018 ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1273504&group_id=5470 From noreply at sourceforge.net Fri Aug 26 06:25:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 21:25:42 -0700 Subject: [ python-Bugs-1119418 ] xrange() builtin accepts keyword arg silently Message-ID: Bugs item #1119418, was opened at 2005-02-09 11:57 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&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: None Status: Open >Resolution: Accepted Priority: 6 Submitted By: Martin Blais (blais) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: xrange() builtin accepts keyword arg silently Initial Comment: Calling ``xrange(10, 100, step=10)`` results in a xrange(10, 100) iterator silently. In contrast, ``range(10, 100, step=10)`` raises an exception. See test program below. Two possible fixes: 1. fix xrange() so that it returns a xrange(10, 100, 10) iterator 2. make sure that xrange() raises an exception too. #!/usr/bin/env python def foo( min_, max_, step=1 ): print min_, max_, step print '====================' foo(10, 100, 10) foo(10, 100, step=10) print '====================' print xrange(10, 100, 10) print xrange(10, 100, step=10) print '====================' print range(10, 100, 10) print range(10, 100, step=10) elbow:/usr/.../lib/python2.4$ /tmp/a.py ==================== 10 100 10 10 100 10 ==================== xrange(10, 100, 10) xrange(10, 100) ==================== [10, 20, 30, 40, 50, 60, 70, 80, 90] Traceback (most recent call last): File "/tmp/a.py", line 16, in ? print range(10, 100, step=10) TypeError: range() takes no keyword arguments > /tmp/a.py(16)?() -> print range(10, 100, step=10) (Pdb) elbow:/usr/.../lib/python2.4$ ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 15:21 Message: Logged In: YES user_id=1188172 Attaching a huge patch. It introduces the function you described, and calls it in the constructors of xrange, set, frozenset, buffer and slice. Moreover, I found it to be necessary in objects in the following modules: - array (array) - itertools (cycle, dropwhile, takewhile, islice, imap, chain, ifilter, count, izip, repeat) - operator (attrgetter, itemgetter) - _random (Random) - zipimport (zipimporter) - collections (deque) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-25 09:35 Message: Logged In: YES user_id=80475 xrange() needs to be kept closely parallel with range() . Accordingly, it should not sprout keyword arguments. For all of these, I think the solution is to raise a TypeError when keyword arguments are supplied to functions/types that don't handle them. Encapsulate the logic in a new internal API function: int _PyArg_NoKeywords(char *funcname, PyObject *kwds) { if (kwds == NULL) return 1; if (!PyDict_CheckExact(kwds)){ bad internal call return 0; } if (PyDict_Size(kwds) == 0) return 1; set_exc_typeerror(funcname does not take kw args) return 0; } Then go through the code finding all the type constructors (grep for PyTypeObject) and add the error check if the kwds arg is being ignored). For example: range_new(PyTypeObject *type, PyObject *args, PyObject *kw) { if (!_PyArg_NoKeywords("xrange", kw)) return NULL; . . . Be sure to add test cases for every constructor that gets changed. Also, go ahead an backport to Py2.4.2. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 08:20 Message: Logged In: YES user_id=1188172 Please review. Should I work on a patch to buffer, set and slice, too? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-09 16:04 Message: Logged In: YES user_id=1188172 I delved deeper into this, and it seems that the difference is caused by range being a method (of bltinmodule, defined as METH_VARARGS), while xrange is a constructor for a rangeobject. Such constructor functions get three arguments (the type object, the args and the kw args), and when the kw args are not checked like in str(), they can pass freely and are ignored. I have attached a patch which changes the range object constructor (xrange) to accept keyword arguments. Other builtin types that need such a correction include buffer, set, slice. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 17:21 Message: Logged In: YES user_id=593130 Functions coded in C generally do not take keyword arguments. (Special coding is required to achieve otherwise.) In 2.2, range and xrange both followed this rule: >>> xrange(1,20,step=2) Traceback (most recent call last): File "", line 1, in ? TypeError: xrange() takes no keyword arguments >>> range(1,20,step=2) Traceback (most recent call last): File "", line 1, in ? TypeError: range() takes no keyword arguments So, removal of the error message by 2.4 seem to be a bug. Surprise: >>> str(object=1) '1' >>> str(i=2) Traceback (most recent call last): File "", line 1, in ? TypeError: 'i' is an invalid keyword argument for this function There is nothing in the doc(Lib Ref) or doc string of str vs. range and xrange that would lead me to expect this. I looked around CVS a bit to see if the past or possible future change was something simple, but I could not find source of error message in bltinmodule.c, ceval.c, getargs.c, rangeobject.c, or typeobject.c, so I will leave this to someone else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&group_id=5470 From noreply at sourceforge.net Fri Aug 26 08:45:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Aug 2005 23:45:57 -0700 Subject: [ python-Bugs-1119418 ] xrange() builtin accepts keyword arg silently Message-ID: Bugs item #1119418, was opened at 2005-02-09 17:57 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&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: None >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Martin Blais (blais) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: xrange() builtin accepts keyword arg silently Initial Comment: Calling ``xrange(10, 100, step=10)`` results in a xrange(10, 100) iterator silently. In contrast, ``range(10, 100, step=10)`` raises an exception. See test program below. Two possible fixes: 1. fix xrange() so that it returns a xrange(10, 100, 10) iterator 2. make sure that xrange() raises an exception too. #!/usr/bin/env python def foo( min_, max_, step=1 ): print min_, max_, step print '====================' foo(10, 100, 10) foo(10, 100, step=10) print '====================' print xrange(10, 100, 10) print xrange(10, 100, step=10) print '====================' print range(10, 100, 10) print range(10, 100, step=10) elbow:/usr/.../lib/python2.4$ /tmp/a.py ==================== 10 100 10 10 100 10 ==================== xrange(10, 100, 10) xrange(10, 100) ==================== [10, 20, 30, 40, 50, 60, 70, 80, 90] Traceback (most recent call last): File "/tmp/a.py", line 16, in ? print range(10, 100, step=10) TypeError: range() takes no keyword arguments > /tmp/a.py(16)?() -> print range(10, 100, step=10) (Pdb) elbow:/usr/.../lib/python2.4$ ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 08:45 Message: Logged In: YES user_id=1188172 Committed. Must the new API function be somehow documented? Commit report follows: Checking in Python/getargs.c; new revision: 2.106; previous revision: 2.105 Checking in Include/modsupport.h; new revision: 2.42; previous revision: 2.41 Checking in Objects/rangeobject.c; new revision: 2.55; previous revision: 2.54 Checking in Objects/setobject.c; new revision: 1.56; previous revision: 1.55 Checking in Objects/bufferobject.c; new revision: 2.27; previous revision: 2.26 Checking in Objects/sliceobject.c; new revision: 2.23; previous revision: 2.22 Checking in Modules/arraymodule.c; new revision: 2.99; previous revision: 2.98 Checking in Modules/itertoolsmodule.c; new revision: 1.41; previous revision: 1.40 Checking in Modules/operator.c; new revision: 2.31; previous revision: 2.30 Checking in Modules/_randommodule.c; new revision: 1.8; previous revision: 1.7 Checking in Modules/zipimport.c; new revision: 1.19; previous revision: 1.18 Checking in Modules/collectionsmodule.c; new revision: 1.39; previous revision: 1.38 Checking in Python/getargs.c; new revision: 2.102.2.3; previous revision: 2.102.2.2 Checking in Include/modsupport.h; new revision: 2.41.4.1; previous revision: 2.41 Checking in Objects/rangeobject.c; new revision: 2.53.2.1; previous revision: 2.53 Checking in Objects/setobject.c; new revision: 1.31.2.4; previous revision: 1.31.2.3 Checking in Objects/bufferobject.c; new revision: 2.26.2.1; previous revision: 2.26 Checking in Objects/sliceobject.c; new revision: 2.22.4.1; previous revision: 2.22 Checking in Modules/arraymodule.c; new revision: 2.97.2.1; previous revision: 2.97 Checking in Modules/itertoolsmodule.c; new revision: 1.39.2.1; previous revision: 1.39 Checking in Modules/operator.c; new revision: 2.29.4.1; previous revision: 2.29 Checking in Modules/_randommodule.c; new revision: 1.7.4.1; previous revision: 1.7 Checking in Modules/zipimport.c; new revision: 1.18.2.1; previous revision: 1.18 Checking in Modules/collectionsmodule.c; new revision: 1.36.2.1; previous revision: 1.36 ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 22:21 Message: Logged In: YES user_id=1188172 Attaching a huge patch. It introduces the function you described, and calls it in the constructors of xrange, set, frozenset, buffer and slice. Moreover, I found it to be necessary in objects in the following modules: - array (array) - itertools (cycle, dropwhile, takewhile, islice, imap, chain, ifilter, count, izip, repeat) - operator (attrgetter, itemgetter) - _random (Random) - zipimport (zipimporter) - collections (deque) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-25 16:35 Message: Logged In: YES user_id=80475 xrange() needs to be kept closely parallel with range() . Accordingly, it should not sprout keyword arguments. For all of these, I think the solution is to raise a TypeError when keyword arguments are supplied to functions/types that don't handle them. Encapsulate the logic in a new internal API function: int _PyArg_NoKeywords(char *funcname, PyObject *kwds) { if (kwds == NULL) return 1; if (!PyDict_CheckExact(kwds)){ bad internal call return 0; } if (PyDict_Size(kwds) == 0) return 1; set_exc_typeerror(funcname does not take kw args) return 0; } Then go through the code finding all the type constructors (grep for PyTypeObject) and add the error check if the kwds arg is being ignored). For example: range_new(PyTypeObject *type, PyObject *args, PyObject *kw) { if (!_PyArg_NoKeywords("xrange", kw)) return NULL; . . . Be sure to add test cases for every constructor that gets changed. Also, go ahead an backport to Py2.4.2. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 15:20 Message: Logged In: YES user_id=1188172 Please review. Should I work on a patch to buffer, set and slice, too? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-09 23:04 Message: Logged In: YES user_id=1188172 I delved deeper into this, and it seems that the difference is caused by range being a method (of bltinmodule, defined as METH_VARARGS), while xrange is a constructor for a rangeobject. Such constructor functions get three arguments (the type object, the args and the kw args), and when the kw args are not checked like in str(), they can pass freely and are ignored. I have attached a patch which changes the range object constructor (xrange) to accept keyword arguments. Other builtin types that need such a correction include buffer, set, slice. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 23:21 Message: Logged In: YES user_id=593130 Functions coded in C generally do not take keyword arguments. (Special coding is required to achieve otherwise.) In 2.2, range and xrange both followed this rule: >>> xrange(1,20,step=2) Traceback (most recent call last): File "", line 1, in ? TypeError: xrange() takes no keyword arguments >>> range(1,20,step=2) Traceback (most recent call last): File "", line 1, in ? TypeError: range() takes no keyword arguments So, removal of the error message by 2.4 seem to be a bug. Surprise: >>> str(object=1) '1' >>> str(i=2) Traceback (most recent call last): File "", line 1, in ? TypeError: 'i' is an invalid keyword argument for this function There is nothing in the doc(Lib Ref) or doc string of str vs. range and xrange that would lead me to expect this. I looked around CVS a bit to see if the past or possible future change was something simple, but I could not find source of error message in bltinmodule.c, ceval.c, getargs.c, rangeobject.c, or typeobject.c, so I will leave this to someone else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&group_id=5470 From noreply at sourceforge.net Fri Aug 26 10:07:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Aug 2005 01:07:00 -0700 Subject: [ python-Bugs-1072182 ] bad arg type to isspace in struct module Message-ID: Bugs item #1072182, was opened at 2004-11-23 18:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072182&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg McFarlane (gregm) >Assigned to: Nobody/Anonymous (nobody) Summary: bad arg type to isspace in struct module Initial Comment: For characters greater than 0x7f, the calls to isspace() in Modules/structmodule.c can return random values. For example, on Solaris I got this (incorrect) output: >>> import struct >>> struct.calcsize('10d\xfed') 88 >>> After changing the three occurrences of "isspace((int)c)" to "isspace((unsigned char)c)", this was the (correct) output: >>> import struct >>> struct.calcsize('10d\xfed') Traceback (most recent call last): File "", line 1, in ? struct.error: bad char in struct format >>> Reason: the '\xfe' is taken as a signed char. The code (int)c converts this to a signed int (-2). The system isspace macro uses this as an index into the __ctype array. The array is only defined for the values 0 to 255 and so -2 is out-of-bounds. The value returned by isspace depends on what happens to be at that location in memory. NOTE: There may be other occurrences of this bug in other parts of the python code. Please check. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-26 03:06 Message: Logged In: YES user_id=80475 Fixed the ones in the struct module. Leaving this report open for someone with time to investigate other occurrences. ---------------------------------------------------------------------- Comment By: Erik Demaine (edemaine) Date: 2004-11-23 23:52 Message: Logged In: YES user_id=265183 Looking at other instances of isspace and friends, I think this is the point of calling Py_CHARMASK, which is used to "Convert a possibly signed character to a nonnegative int" (depending on whether 'char' is signed or unsigned). In other words, I believe the three instances of isspace((int)c) in Modules/structmodule.c should be changed to isspace(Py_CHARMASK(c)). `grep isspace */*.c | grep -v CHARMASK` suggests some other potential bugs: - Modules/posixmodule.c:466 (os2_formatmsg): isspace(*lastc) - Modules/socketmodule.c:504 (set_error): isspace(*lastc) `egrep 'isalnum|isalpha|isascii|isblank|iscntrl|isdigit|isgraph|islower|isprint|isprint|ispunct|isupper|isxdigit' */*.c | grep -v Py_CHARMASK` suggest the following further bugs: - Modules/_hotshot.c:1431 (get_version_string): isdigit((int)*rev) [unlikely to cause trouble, but wrong in the same way...] - Modules/_tkinter.c:639 (Tkapp_New): isupper((int)argv0[0]) - Modules/pyexpat.c:1800 (get_version_string): isdigit((int)*rev) [again unlikely a problem] - Modules/stropmodule.c:760 (strop_atoi): isalnum((int)end[-1]) ye - Parser/grammar.c:183 (translabel): isalpha((int)(lb->lb_str[1])) - Parser/tokenizer.c:232 (get_coding_spec): isalnum((int)t[0]) - Parser/atof.c:16 (atof): (c = *s++) != '\0' && isdigit(c) [same problem appears three times in the same function] - Python/compile.c:1721,1727 (parsestr): int quote = *s; ... isalpha(quote) - Python/dynload_aix.c:147 (aix_loaderror): isdigit(*message[i]) - Python/getargs.c:141 (vgetargs1): int c = *format++ (and later, isalpha(c)) - Python/getargcs.c:258 (vgetargs1): isalpha((int)(*format)) - Python/getargs.c:336 (converttuple): int c = *format++ (and later, isalpha(c)) - Python/getargs.c:1222 (vgetargskeyword): i = *format++ (and later, isalpha(i)) That's all that I could find. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072182&group_id=5470 From noreply at sourceforge.net Fri Aug 26 10:18:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Aug 2005 01:18:04 -0700 Subject: [ python-Bugs-849662 ] reading shelves is really slow Message-ID: Bugs item #849662, was opened at 2003-11-26 09:06 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849662&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Gottfried Gan?auge (ganssauge) >Assigned to: Nobody/Anonymous (nobody) Summary: reading shelves is really slow Initial Comment: My application uses a shelve-file which is created by another process using the same python version. Before python2.3 using this shelve with the exact same application was almost twice as fast as a binary pickle containing the same data. Now with python2.3 the same application is suddenly about 150 times slower than using the binary pickle. The usage is as follows: idx_dict = shelve.open (idx_dict_name, "r") ... while not infile.eof: index = get_index_from_somewhere_else() if not idx_dict.has_key (index): do_something(index) else: do_something_else(index) idx.dict.close() Profiling revealed that most of the time is spent within userdict. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-07 06:55 Message: Logged In: YES user_id=80475 I fixed-up your particular problem for Py2.3.3 and Py2.4. Leaving the report open because there are other calls which have performance issues. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-28 16:57 Message: Logged In: YES user_id=80475 Yes, that was the culprit. I'll look for a way to make __cmp__ a bit smarter. In the meantime, the proper way to check for None is always: if dict is None. ---------------------------------------------------------------------- Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-11-28 11:01 Message: Logged In: YES user_id=792746 I think I found the answer: apart from has_key() I'm using "dict != None". If I leave that out in my test program both python variants run with the same speed. The dict != None condition seems to trigger len(dict.keys()) and that seems to be way slower than before. I definitely didn't time different scripts: the script is part of our CDROM production system and the only variables I had during my tests were python itself and the python path. Find my test script attached... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-27 12:55 Message: Logged In: YES user_id=80475 The fragment in the original posting showed the only inner-loop shelve access was through has_key(). The tracebacks show that UserDict is nowhere in the traceback chain. I conclude that the fragment does not represent what is really going on in the problematic script. So, please attach the profiled script, Konvertierung/entsch_pass2.py The attached profile indicates that somewhere, there is a line like: for k,v in idx_dict.iteritems(). This is surprising because shelves did not support iteritems() in Py2.2. That would be mean that you've timed and compared two different pieces of code. Please show the shortest script with data that runs at radically different speeds on Py2.2 vs Py2.3. ---------------------------------------------------------------------- Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-11-27 05:42 Message: Logged In: YES user_id=792746 What the heck ... here is the shelve in question ---------------------------------------------------------------------- Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-11-27 05:32 Message: Logged In: YES user_id=792746 I uploaded my profiling data, maybe it will help you ... Here is the information you requested: ----------------><------------------------><------------ (gotti at gglinux 534) PYTHONPATH=../../../COMMON.DEVEL/Tools/python/lib.linux- i686-2.3 python Konvertierung/entsch_pass2.py HI69228 x HR all_idx2.shelve <hi69228.sgml Traceback (most recent call last): File "Konvertierung/entsch_pass2.py", line 1026, in ? init_idx_dict (idx_dict_name) File "../../COMMON/lib/EDB.py", line 54, in init_idx_dict idx_dict.has_key([]) File "/usr/lib/python2.3/shelve.py", line 104, in has_key return self.dict.has_key(key) File "/usr/lib/python2.3/bsddb/__init__.py", line 142, in has_key return self.db.has_key(key) TypeError: String or Integer object expected for key, list found (gotti at gglinux 535) PYTHONPATH=../../../COMMON.DEVEL/Tools/python/lib.linux- i686-2.2 python2.2 Konvertierung/entsch_pass2.py HI69228 x HR all_idx2.shelve <hi69228.sgml Traceback (most recent call last): File "Konvertierung/entsch_pass2.py", line 1026, in ? init_idx_dict (idx_dict_name) File "../../COMMON/lib/EDB.py", line 54, in init_idx_dict idx_dict.has_key([]) File "/usr/lib/python2.2/shelve.py", line 62, in has_key return self.dict.has_key(key) TypeError: key type must be string (gotti at gglinux 536) python -V Python 2.3.2 (gotti at gglinux 537) python2.2 -V Python 2.2.3 (gotti at gglinux 538) uname -a Linux gglinux 2.4.22 #1 SMP Mon Nov 3 11:40:28 CET 2003 i686 unknown unknown GNU/Linux (gotti at gglinux 538) cat /etc/debian_version testing/unstable (gotti at gglinux 539) python2.2 -c 'import shelve ; d = shelve.open("all_idx2.shelve", "r"); print len (d.keys()) ; print d.keys()[0], d [d.keys()[0]]' 34983 HI568817 None (gotti at gglinux 540) python2.3 -c 'import shelve ; d = shelve.open("all_idx2.shelve", "r"); print "# items in shelve:", len (d.keys()) ; print "Items look like: index", d.keys() [0], "value", d [d.keys()[0]]' # items in shelve: 34983 Items look like: index HI568817 value None ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-27 04:17 Message: Logged In: YES user_id=80475 I can reproduce a four-fold slowdown that persists even after the UserDict.DictMixin lines are commented out of shelve.py and bsddb.__init__.py. For me, the only thing that has changed is the underlying bsddb implementation. Let's see if you system is going somewhere else to get its shelving done. After the first line, add: idx_dict.has_key ([]) Then post the traceback here. Do that for both Py2.2 and for Py2.3. Thank you. Also, post what a typical record in the index and tell me how many entries are typically in idx_dict. That way, I can try to reproduce your timings with greater fidelity. Which os are you using and what the minor bugfix verion numbers of the Py2.2 and PY2.3 you are using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849662&group_id=5470 From noreply at sourceforge.net Fri Aug 26 10:19:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Aug 2005 01:19:58 -0700 Subject: [ python-Bugs-1234674 ] filecmp.cmp's "shallow" option Message-ID: Bugs item #1234674, was opened at 2005-07-08 11:01 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234674&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: Mendez (goatsofmendez) >Assigned to: Raymond Hettinger (rhettinger) Summary: filecmp.cmp's "shallow" option Initial Comment: The filecmp.cmp function has a shallow option (set as default) to only compare files based on stats rather than doing a bit by bit comparison of the file itself. The relevant bit of the code follows. s1 = _sig(os.stat(f1)) s2 = _sig(os.stat(f2)) if s1[0] != stat.S_IFREG or s2[0] != stat.S_IFREG: return False if shallow and s1 == s2: return True if s1[1] != s2[1]: return False result = _cache.get((f1, f2)) if result and (s1, s2) == result[:2]: return result[2] outcome = _do_cmp(f1, f2) _cache[f1, f2] = s1, s2, outcome return outcome There's a check to see if the shallow mode is enabled and if that's the case and the stats match it returns true but the test for returning false is for only one of the stats attributes meaning that it's possible for a file not to match either test and the function to carry on to the full file check lower down. The check above to see if the stats match with stat.S_IFREG also looks wrong to me, but it could just be I don't understand what he's trying to do :) This code is the same in both 2.3 and 2.4 ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 10:19 Message: Logged In: YES user_id=1188172 Hm. Looks like if the size is identical, but the mtime is not, the file will be read even in shallow mode. The filecmp docs say "Unless shallow is given and is false, files with identical os.stat() signatures are taken to be equal." The filecmp.cmp docstring says "shallow: Just check stat signature (do not read the files)" Two questions arise: - Should the file contents be compared in shallow mode if the mtimes do not match? - Should the mtimes matter in non-shallow mode? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234674&group_id=5470 From noreply at sourceforge.net Fri Aug 26 10:33:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Aug 2005 01:33:58 -0700 Subject: [ python-Bugs-1234674 ] filecmp.cmp's "shallow" option Message-ID: Bugs item #1234674, was opened at 2005-07-08 04:01 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234674&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: Mendez (goatsofmendez) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: filecmp.cmp's "shallow" option Initial Comment: The filecmp.cmp function has a shallow option (set as default) to only compare files based on stats rather than doing a bit by bit comparison of the file itself. The relevant bit of the code follows. s1 = _sig(os.stat(f1)) s2 = _sig(os.stat(f2)) if s1[0] != stat.S_IFREG or s2[0] != stat.S_IFREG: return False if shallow and s1 == s2: return True if s1[1] != s2[1]: return False result = _cache.get((f1, f2)) if result and (s1, s2) == result[:2]: return result[2] outcome = _do_cmp(f1, f2) _cache[f1, f2] = s1, s2, outcome return outcome There's a check to see if the shallow mode is enabled and if that's the case and the stats match it returns true but the test for returning false is for only one of the stats attributes meaning that it's possible for a file not to match either test and the function to carry on to the full file check lower down. The check above to see if the stats match with stat.S_IFREG also looks wrong to me, but it could just be I don't understand what he's trying to do :) This code is the same in both 2.3 and 2.4 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-26 03:33 Message: Logged In: YES user_id=80475 Fred, do you have thoughts on this patch? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 03:19 Message: Logged In: YES user_id=1188172 Hm. Looks like if the size is identical, but the mtime is not, the file will be read even in shallow mode. The filecmp docs say "Unless shallow is given and is false, files with identical os.stat() signatures are taken to be equal." The filecmp.cmp docstring says "shallow: Just check stat signature (do not read the files)" Two questions arise: - Should the file contents be compared in shallow mode if the mtimes do not match? - Should the mtimes matter in non-shallow mode? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234674&group_id=5470 From noreply at sourceforge.net Fri Aug 26 10:38:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Aug 2005 01:38:03 -0700 Subject: [ python-Bugs-1239186 ] Install Error: "cannot compute sizeof (int), 77" Message-ID: Bugs item #1239186, was opened at 2005-07-16 00:00 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239186&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: Closed >Resolution: Invalid Priority: 5 Submitted By: Bob Gazzale (rgazzale) Assigned to: Nobody/Anonymous (nobody) Summary: Install Error: "cannot compute sizeof (int), 77" Initial Comment: Computer: Mac OS: Tiger 10.4.2 When attempting to install Python 2.4, I get the following error message in the "configure" stage: "checking size of int... configure: error: cannot compute sizeof (int), 77" config.log is attached. Many thanks, Bob ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 10:38 Message: Logged In: YES user_id=1188172 As one can see from config.log, this is a fault in the GCC 4.1.0 header files. The file "machine/ansi.h" is missing. Closing as Invalid. ---------------------------------------------------------------------- Comment By: Bob Gazzale (rgazzale) Date: 2005-07-17 15:48 Message: Logged In: YES user_id=1313508 I am using the gcc I downloaded from Gaurav Khanna's HPC site. Thanks for the lead. I'll try going back to a non-experimental version of gcc. Bob ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-07-16 00:23 Message: Logged In: YES user_id=357491 Are you using the standard version of gcc that comes with Tiger? I noticed in the log it says ``gcc (GCC) 4.1.0 20050517 (experimental)`` and I thought Tiger had gcc 4.0 (I can't check right now since I am at work), let alone came with a non-experimental version. Regardless, I don't see how it could be the configure files fault since Python does not have any control over the C compiler being able to determine the size of int. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239186&group_id=5470 From noreply at sourceforge.net Fri Aug 26 10:39:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Aug 2005 01:39:42 -0700 Subject: [ python-Bugs-1234473 ] configure: error: cannot compute sizeof (int), 77 Message-ID: Bugs item #1234473, was opened at 2005-07-08 00:37 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234473&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: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tekhne (tekhne0) Assigned to: Nobody/Anonymous (nobody) Summary: configure: error: cannot compute sizeof (int), 77 Initial Comment: After running: shell# configure --prefix=/opt/python Various warnings were produced, and one fatal error preventing the build from progressing: checking size of int... configure: error: cannot compute sizeof (int), 77 The attachment contains the config.log file from the configure command. Build was done with Python 2.4.1 on Solaris 10 (sparc) with gcc 3.3.2. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 10:39 Message: Logged In: YES user_id=1188172 I don't have a Solaris 10 available; it seems that some #define that configure thinks is necessary has a detrimental effect on the /usr/include/sys/siginfo.h header file. ---------------------------------------------------------------------- Comment By: Tekhne (tekhne0) Date: 2005-07-08 00:44 Message: Logged In: YES user_id=1309274 attachment didn't go through...trying again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234473&group_id=5470 From noreply at sourceforge.net Fri Aug 26 10:48:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Aug 2005 01:48:44 -0700 Subject: [ python-Bugs-1263635 ] type() and isinstance() do not call __getattribute__ Message-ID: Bugs item #1263635, was opened at 2005-08-18 21:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263635&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: Per Vognsen (pervognsen) Assigned to: Nobody/Anonymous (nobody) Summary: type() and isinstance() do not call __getattribute__ Initial Comment: The built-in functions type() and isinstance() do not call __getattribute__ for instances of user-defined classes. Thus, for instance, x.__class__ == sometype and type(x) == sometype can give inconsistent results. I ran into this problem in writing a transparent persistence system, where instances of proxy classes are used as stand-ins for unloaded objects and the proxy does just-in-time loading by overloading __getattribute__ and __setattr__ (which changes __class__). (This applies to 2.4.1.) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-26 03:48 Message: Logged In: YES user_id=80475 I don't think this is going to change. A number of builtins directly access an object's structure and do not respect overrides via __getattribute__. This is somewhat intrinsic the Python's current design. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263635&group_id=5470 From noreply at sourceforge.net Fri Aug 26 10:52:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Aug 2005 01:52:00 -0700 Subject: [ python-Bugs-1261659 ] Tutorial doesn't cover * and ** function calls Message-ID: Bugs item #1261659, was opened at 2005-08-17 00:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261659&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: None Status: Open Resolution: None >Priority: 6 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial doesn't cover * and ** function calls Initial Comment: While the tutorial, in the section discussing function definitions, covers * and ** arguments, there is no aparent coverage of using them in a function call (e.g., ``open(*["file", "r"])``). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-26 03:51 Message: Logged In: YES user_id=80475 That should be fixed. Do you have a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261659&group_id=5470 From noreply at sourceforge.net Fri Aug 26 11:40:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Aug 2005 02:40:29 -0700 Subject: [ python-Bugs-1273892 ] Encoding memory problem. Message-ID: Bugs item #1273892, was opened at 2005-08-26 11:40 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=1273892&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: None Priority: 5 Submitted By: Darek Ostolski (ostolski) Assigned to: Nobody/Anonymous (nobody) Summary: Encoding memory problem. Initial Comment: When you execute command import select python crashes under windows XP/2000 I think this bug inside Python interpreter. However when you remove first line or remove comments this command executes fine under Python 2.4 but still crash under Python 2.4.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1273892&group_id=5470 From noreply at sourceforge.net Fri Aug 26 11:46:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Aug 2005 02:46:22 -0700 Subject: [ python-Bugs-1273892 ] Encoding memory problem. Message-ID: Bugs item #1273892, was opened at 2005-08-26 11:40 Message generated for change (Settings changed) made by ostolski You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1273892&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: None >Priority: 9 Submitted By: Darek Ostolski (ostolski) Assigned to: Nobody/Anonymous (nobody) Summary: Encoding memory problem. Initial Comment: When you execute command import select python crashes under windows XP/2000 I think this bug inside Python interpreter. However when you remove first line or remove comments this command executes fine under Python 2.4 but still crash under Python 2.4.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1273892&group_id=5470 From noreply at sourceforge.net Fri Aug 26 11:47:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Aug 2005 02:47:04 -0700 Subject: [ python-Bugs-1261229 ] __new__ is class method Message-ID: Bugs item #1261229, was opened at 2005-08-16 19:53 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261229&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: None >Status: Open Resolution: Fixed Priority: 5 Submitted By: Mike Orr (hierro) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: __new__ is class method Initial Comment: Section 3.3.1 of the Language Reference says, " __new__() is a static method" But it's actually a class method since it's first argument is the class. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-08-26 10:47 Message: Logged In: YES user_id=6656 Argh! Confusing as it is, __new__ really *is* a static method: >>> class C(object): ... def __new__(cls, name, bases, ns): ... pass ... >>> C.__dict__['__new__'] so please revert this. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 22:57 Message: Logged In: YES user_id=1188172 Thanks for the report, fixed in Doc/ref/ref3.tex r1.127, 1.121.2.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261229&group_id=5470 From noreply at sourceforge.net Fri Aug 26 12:17:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Aug 2005 03:17:36 -0700 Subject: [ python-Bugs-1273892 ] Encoding memory problem. Message-ID: Bugs item #1273892, was opened at 2005-08-26 11:40 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1273892&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: Closed >Resolution: Out of Date >Priority: 5 Submitted By: Darek Ostolski (ostolski) Assigned to: Nobody/Anonymous (nobody) Summary: Encoding memory problem. Initial Comment: When you execute command import select python crashes under windows XP/2000 I think this bug inside Python interpreter. However when you remove first line or remove comments this command executes fine under Python 2.4 but still crash under Python 2.4.1 ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-08-26 12:17 Message: Logged In: YES user_id=89016 This bug is already fixed in the current CVS version (which will prbably be released as 2.4.2 in mid-September). select.py imports properly on both Windows and Linux. Closing as "Out Of Date". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1273892&group_id=5470 From noreply at sourceforge.net Fri Aug 26 13:38:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Aug 2005 04:38:10 -0700 Subject: [ python-Bugs-1234674 ] filecmp.cmp's "shallow" option Message-ID: Bugs item #1234674, was opened at 2005-07-08 09:01 Message generated for change (Comment added) made by goatsofmendez You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234674&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: Mendez (goatsofmendez) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: filecmp.cmp's "shallow" option Initial Comment: The filecmp.cmp function has a shallow option (set as default) to only compare files based on stats rather than doing a bit by bit comparison of the file itself. The relevant bit of the code follows. s1 = _sig(os.stat(f1)) s2 = _sig(os.stat(f2)) if s1[0] != stat.S_IFREG or s2[0] != stat.S_IFREG: return False if shallow and s1 == s2: return True if s1[1] != s2[1]: return False result = _cache.get((f1, f2)) if result and (s1, s2) == result[:2]: return result[2] outcome = _do_cmp(f1, f2) _cache[f1, f2] = s1, s2, outcome return outcome There's a check to see if the shallow mode is enabled and if that's the case and the stats match it returns true but the test for returning false is for only one of the stats attributes meaning that it's possible for a file not to match either test and the function to carry on to the full file check lower down. The check above to see if the stats match with stat.S_IFREG also looks wrong to me, but it could just be I don't understand what he's trying to do :) This code is the same in both 2.3 and 2.4 ---------------------------------------------------------------------- >Comment By: Mendez (goatsofmendez) Date: 2005-08-26 11:38 Message: Logged In: YES user_id=1309441 On my own system I've modified the testing code as follows if s1 != s2: return False if shallow and s1 == s2: return True Which works as I expected it to work If attributes aren't identical - Always fails If the attributes are identical and it's in shallow mode - returns true If the attributes are identical and it's not in shallow mode - goes on to check if the files are byte identical. Whether there should be additional modes for finding byte identical files with different names, attributes etc. is another matter. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-26 08:33 Message: Logged In: YES user_id=80475 Fred, do you have thoughts on this patch? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 08:19 Message: Logged In: YES user_id=1188172 Hm. Looks like if the size is identical, but the mtime is not, the file will be read even in shallow mode. The filecmp docs say "Unless shallow is given and is false, files with identical os.stat() signatures are taken to be equal." The filecmp.cmp docstring says "shallow: Just check stat signature (do not read the files)" Two questions arise: - Should the file contents be compared in shallow mode if the mtimes do not match? - Should the mtimes matter in non-shallow mode? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234674&group_id=5470 From noreply at sourceforge.net Fri Aug 26 14:56:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Aug 2005 05:56:56 -0700 Subject: [ python-Bugs-1261229 ] __new__ is class method Message-ID: Bugs item #1261229, was opened at 2005-08-16 20:53 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261229&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: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Mike Orr (hierro) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: __new__ is class method Initial Comment: Section 3.3.1 of the Language Reference says, " __new__() is a static method" But it's actually a class method since it's first argument is the class. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 14:56 Message: Logged In: YES user_id=1188172 Okay, reverted in Doc/ref/ref3.tex 1.128, 1.121.2.7. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-08-26 11:47 Message: Logged In: YES user_id=6656 Argh! Confusing as it is, __new__ really *is* a static method: >>> class C(object): ... def __new__(cls, name, bases, ns): ... pass ... >>> C.__dict__['__new__'] so please revert this. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 23:57 Message: Logged In: YES user_id=1188172 Thanks for the report, fixed in Doc/ref/ref3.tex r1.127, 1.121.2.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261229&group_id=5470 From noreply at sourceforge.net Fri Aug 26 16:25:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Aug 2005 07:25:51 -0700 Subject: [ python-Bugs-1274069 ] bz2module.c compiler warning Message-ID: Bugs item #1274069, was opened at 2005-08-26 10:25 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=1274069&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: bz2module.c compiler warning Initial Comment: On Python HEAD, there's a new warning while compiling bz2module.c (MSVC 7.1): python\Modules\bz2module.c(1095) : warning C4244: '=' : conversion from 'Py_off_t' to 'int', possible loss of data Looks like a legitimate complaint to me. The line in question: readsize = offset-bytesread; Those have types int, Py_off_t, and int respectively. Is it true that offset-bytesread _necessarily_ fits in an int? If so, a comment should explain why, and a cast should be added to squash the warning. Or If the difference doesn't necessarily fit in an int, the code is wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&group_id=5470 From noreply at sourceforge.net Fri Aug 26 17:05:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Aug 2005 08:05:27 -0700 Subject: [ python-Bugs-1274069 ] bz2module.c compiler warning Message-ID: Bugs item #1274069, was opened at 2005-08-26 16:25 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: bz2module.c compiler warning Initial Comment: On Python HEAD, there's a new warning while compiling bz2module.c (MSVC 7.1): python\Modules\bz2module.c(1095) : warning C4244: '=' : conversion from 'Py_off_t' to 'int', possible loss of data Looks like a legitimate complaint to me. The line in question: readsize = offset-bytesread; Those have types int, Py_off_t, and int respectively. Is it true that offset-bytesread _necessarily_ fits in an int? If so, a comment should explain why, and a cast should be added to squash the warning. Or If the difference doesn't necessarily fit in an int, the code is wrong. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 17:05 Message: Logged In: YES user_id=1188172 I think declaring readsize as size_t should fix the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&group_id=5470 From noreply at sourceforge.net Fri Aug 26 23:31:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Aug 2005 14:31:18 -0700 Subject: [ python-Bugs-1274324 ] 'setup.py install' fail on linux from read-only storage Message-ID: Bugs item #1274324, was opened at 2005-08-27 00:31 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=1274324&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: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belchenko (bialix) Assigned to: Nobody/Anonymous (nobody) Summary: 'setup.py install' fail on linux from read-only storage Initial Comment: I'm trying to install some package on linux from read-only storage (pex, CD-ROM), and process has been crashed. After copying first file from build/lib directory I have error message. I run setup script with command: python setup.py install --skip-build -f --no-compile Directory build/lib contain builded python scripts (and extensions). If I try to install from hard disk -- all OK. If try to install from read-only devices -- process breaked. I have this error message: error: /usr/lib/python2.4/site-package/module/__init__.py: Invalid argument Error message appear after successful copying file __init__.py. If copying directory with all files to install from CD-ROM to hard drive and then launch setup.py, then it is works fine. Tested on: * linux2 + python 2.3 * cygwin + python 2.4 On windows it is works OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274324&group_id=5470 From noreply at sourceforge.net Sat Aug 27 12:30:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 27 Aug 2005 03:30:08 -0700 Subject: [ python-Bugs-1274069 ] bz2module.c compiler warning Message-ID: Bugs item #1274069, was opened at 2005-08-26 16:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: bz2module.c compiler warning Initial Comment: On Python HEAD, there's a new warning while compiling bz2module.c (MSVC 7.1): python\Modules\bz2module.c(1095) : warning C4244: '=' : conversion from 'Py_off_t' to 'int', possible loss of data Looks like a legitimate complaint to me. The line in question: readsize = offset-bytesread; Those have types int, Py_off_t, and int respectively. Is it true that offset-bytesread _necessarily_ fits in an int? If so, a comment should explain why, and a cast should be added to squash the warning. Or If the difference doesn't necessarily fit in an int, the code is wrong. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-27 12:30 Message: Logged In: YES user_id=21627 Clearly, the difference is bound by buffersize (since, if it is larger, readsize is set to buffersize). buffersize is initialized to SMALLCHUNK, which is 8192, and never changed, so yes, the difference fits to an int an all supported platforms. OTOH, the condition of the if statement is bogus: if ((size_t)offset-bytesread > buffersize) offset is of type Py_off_t, which is a 64-bit type on most platforms. Casting it to size_t causes truncation on 32-bit platforms. Furthermore, I think self->pos should be of type Py_off_t, as it will wrap around for files larger >2GB on 32-bit platforms; the same for self->size. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 17:05 Message: Logged In: YES user_id=1188172 I think declaring readsize as size_t should fix the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&group_id=5470 From noreply at sourceforge.net Sat Aug 27 14:27:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 27 Aug 2005 05:27:01 -0700 Subject: [ python-Bugs-1274069 ] bz2module.c compiler warning Message-ID: Bugs item #1274069, was opened at 2005-08-26 16:25 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: bz2module.c compiler warning Initial Comment: On Python HEAD, there's a new warning while compiling bz2module.c (MSVC 7.1): python\Modules\bz2module.c(1095) : warning C4244: '=' : conversion from 'Py_off_t' to 'int', possible loss of data Looks like a legitimate complaint to me. The line in question: readsize = offset-bytesread; Those have types int, Py_off_t, and int respectively. Is it true that offset-bytesread _necessarily_ fits in an int? If so, a comment should explain why, and a cast should be added to squash the warning. Or If the difference doesn't necessarily fit in an int, the code is wrong. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 14:27 Message: Logged In: YES user_id=1188172 Attaching patch for f->pos and f->size as Py_off_t. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-27 12:30 Message: Logged In: YES user_id=21627 Clearly, the difference is bound by buffersize (since, if it is larger, readsize is set to buffersize). buffersize is initialized to SMALLCHUNK, which is 8192, and never changed, so yes, the difference fits to an int an all supported platforms. OTOH, the condition of the if statement is bogus: if ((size_t)offset-bytesread > buffersize) offset is of type Py_off_t, which is a 64-bit type on most platforms. Casting it to size_t causes truncation on 32-bit platforms. Furthermore, I think self->pos should be of type Py_off_t, as it will wrap around for files larger >2GB on 32-bit platforms; the same for self->size. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 17:05 Message: Logged In: YES user_id=1188172 I think declaring readsize as size_t should fix the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&group_id=5470 From noreply at sourceforge.net Sat Aug 27 14:55:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 27 Aug 2005 05:55:02 -0700 Subject: [ python-Bugs-1274069 ] bz2module.c compiler warning Message-ID: Bugs item #1274069, was opened at 2005-08-26 16:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: bz2module.c compiler warning Initial Comment: On Python HEAD, there's a new warning while compiling bz2module.c (MSVC 7.1): python\Modules\bz2module.c(1095) : warning C4244: '=' : conversion from 'Py_off_t' to 'int', possible loss of data Looks like a legitimate complaint to me. The line in question: readsize = offset-bytesread; Those have types int, Py_off_t, and int respectively. Is it true that offset-bytesread _necessarily_ fits in an int? If so, a comment should explain why, and a cast should be added to squash the warning. Or If the difference doesn't necessarily fit in an int, the code is wrong. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-08-27 14:55 Message: Logged In: YES user_id=21627 As Tim says: the cast deserves a comment, explaining why it cannot overflow. Even when readsize is size_t, it might still overflow, since Py_off_t might be wider than size_t. Apart from that, the patch looks good - but I can't check whether it silences the warning on Windows. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 14:27 Message: Logged In: YES user_id=1188172 Attaching patch for f->pos and f->size as Py_off_t. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-27 12:30 Message: Logged In: YES user_id=21627 Clearly, the difference is bound by buffersize (since, if it is larger, readsize is set to buffersize). buffersize is initialized to SMALLCHUNK, which is 8192, and never changed, so yes, the difference fits to an int an all supported platforms. OTOH, the condition of the if statement is bogus: if ((size_t)offset-bytesread > buffersize) offset is of type Py_off_t, which is a 64-bit type on most platforms. Casting it to size_t causes truncation on 32-bit platforms. Furthermore, I think self->pos should be of type Py_off_t, as it will wrap around for files larger >2GB on 32-bit platforms; the same for self->size. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 17:05 Message: Logged In: YES user_id=1188172 I think declaring readsize as size_t should fix the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&group_id=5470 From noreply at sourceforge.net Sat Aug 27 16:36:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 27 Aug 2005 07:36:01 -0700 Subject: [ python-Bugs-1274069 ] bz2module.c compiler warning Message-ID: Bugs item #1274069, was opened at 2005-08-26 16:25 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: bz2module.c compiler warning Initial Comment: On Python HEAD, there's a new warning while compiling bz2module.c (MSVC 7.1): python\Modules\bz2module.c(1095) : warning C4244: '=' : conversion from 'Py_off_t' to 'int', possible loss of data Looks like a legitimate complaint to me. The line in question: readsize = offset-bytesread; Those have types int, Py_off_t, and int respectively. Is it true that offset-bytesread _necessarily_ fits in an int? If so, a comment should explain why, and a cast should be added to squash the warning. Or If the difference doesn't necessarily fit in an int, the code is wrong. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 16:36 Message: Logged In: YES user_id=1188172 Okay, next try. Someone with Windows should check this before I check in. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-27 14:55 Message: Logged In: YES user_id=21627 As Tim says: the cast deserves a comment, explaining why it cannot overflow. Even when readsize is size_t, it might still overflow, since Py_off_t might be wider than size_t. Apart from that, the patch looks good - but I can't check whether it silences the warning on Windows. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 14:27 Message: Logged In: YES user_id=1188172 Attaching patch for f->pos and f->size as Py_off_t. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-27 12:30 Message: Logged In: YES user_id=21627 Clearly, the difference is bound by buffersize (since, if it is larger, readsize is set to buffersize). buffersize is initialized to SMALLCHUNK, which is 8192, and never changed, so yes, the difference fits to an int an all supported platforms. OTOH, the condition of the if statement is bogus: if ((size_t)offset-bytesread > buffersize) offset is of type Py_off_t, which is a 64-bit type on most platforms. Casting it to size_t causes truncation on 32-bit platforms. Furthermore, I think self->pos should be of type Py_off_t, as it will wrap around for files larger >2GB on 32-bit platforms; the same for self->size. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 17:05 Message: Logged In: YES user_id=1188172 I think declaring readsize as size_t should fix the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&group_id=5470 From noreply at sourceforge.net Sat Aug 27 18:31:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 27 Aug 2005 09:31:35 -0700 Subject: [ python-Bugs-1274069 ] bz2module.c compiler warning Message-ID: Bugs item #1274069, was opened at 2005-08-26 09:25 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: bz2module.c compiler warning Initial Comment: On Python HEAD, there's a new warning while compiling bz2module.c (MSVC 7.1): python\Modules\bz2module.c(1095) : warning C4244: '=' : conversion from 'Py_off_t' to 'int', possible loss of data Looks like a legitimate complaint to me. The line in question: readsize = offset-bytesread; Those have types int, Py_off_t, and int respectively. Is it true that offset-bytesread _necessarily_ fits in an int? If so, a comment should explain why, and a cast should be added to squash the warning. Or If the difference doesn't necessarily fit in an int, the code is wrong. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-27 11:31 Message: Logged In: YES user_id=80475 The latest patch gives me the following: --------------------Configuration: bz2 - Win32 Debug-------------------- Compiling... bz2module.c C:\py25\Modules\bz2module.c(1143) : warning C4244: 'function' : conversion from '__int64 ' to 'long ', possible loss of data C:\py25\Modules\bz2module.c(1143) : warning C4761: integral size mismatch in argument; conversion supplied lib /out:libbz2.lib blocksort.obj huffman.obj crctable.obj randtable.obj compress.obj decompress.obj bzlib.obj Microsoft (R) Library Manager Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. cl -DWIN32 -MD -Ox -D_FILE_OFFSET_BITS=64 -nologo -o bzip2 bzip2.c libbz2.lib setargv.obj bzip2.c cl -DWIN32 -MD -Ox -D_FILE_OFFSET_BITS=64 -nologo -o bzip2recover bzip2recover.c bzip2recover.c type words1 Doing 6 tests (3 compress, 3 uncompress) ... If there's a problem, things might stop at this point. .\bzip2 -1 < sample1.ref > sample1.rb2 .\bzip2 -2 < sample2.ref > sample2.rb2 .\bzip2 -3 < sample3.ref > sample3.rb2 .\bzip2 -d < sample1.bz2 > sample1.tst .\bzip2 -d < sample2.bz2 > sample2.tst .\bzip2 -ds < sample3.bz2 > sample3.tst All six of the fc's should find no differences. If fc finds an error on sample3.bz2, this could be because WinZip's 'TAR file smart CR/LF conversion' is too clever for its own good. Disable this option. The correct size for sample3.ref is 120,244. If it is 150,251, WinZip has messed it up. fc sample1.bz2 sample1.rb2 Comparing files sample1.bz2 and sample1.rb2 FC: no differences encountered fc sample2.bz2 sample2.rb2 Comparing files sample2.bz2 and sample2.rb2 FC: no differences encountered fc sample3.bz2 sample3.rb2 Comparing files sample3.bz2 and sample3.rb2 ****** sample3.bz2 BZh31AY&SY??3? ??uU???`??2 ???I%@? ??????^??1 ????????????)????al?Dh3H???\mIL?hii??B?R? ****** sample3.rb2 BZh31AY&SY???> ?# ?A?J3?????z? ??7U?{??C2 ?l }??? ****** fc sample1.tst sample1.ref Comparing files sample1.tst and sample1.ref FC: no differences encountered fc sample2.tst sample2.ref Comparing files sample2.tst and sample2.ref FC: no differences encountered fc sample3.tst sample3.ref Comparing files sample3.tst and sample3.ref FC: no differences encountered Linking... bz2_d.pyd - 1 error(s), 2 warning(s) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 09:36 Message: Logged In: YES user_id=1188172 Okay, next try. Someone with Windows should check this before I check in. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-27 07:55 Message: Logged In: YES user_id=21627 As Tim says: the cast deserves a comment, explaining why it cannot overflow. Even when readsize is size_t, it might still overflow, since Py_off_t might be wider than size_t. Apart from that, the patch looks good - but I can't check whether it silences the warning on Windows. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 07:27 Message: Logged In: YES user_id=1188172 Attaching patch for f->pos and f->size as Py_off_t. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-27 05:30 Message: Logged In: YES user_id=21627 Clearly, the difference is bound by buffersize (since, if it is larger, readsize is set to buffersize). buffersize is initialized to SMALLCHUNK, which is 8192, and never changed, so yes, the difference fits to an int an all supported platforms. OTOH, the condition of the if statement is bogus: if ((size_t)offset-bytesread > buffersize) offset is of type Py_off_t, which is a 64-bit type on most platforms. Casting it to size_t causes truncation on 32-bit platforms. Furthermore, I think self->pos should be of type Py_off_t, as it will wrap around for files larger >2GB on 32-bit platforms; the same for self->size. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 10:05 Message: Logged In: YES user_id=1188172 I think declaring readsize as size_t should fix the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&group_id=5470 From noreply at sourceforge.net Sat Aug 27 19:02:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 27 Aug 2005 10:02:43 -0700 Subject: [ python-Bugs-1274069 ] bz2module.c compiler warning Message-ID: Bugs item #1274069, was opened at 2005-08-26 16:25 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: bz2module.c compiler warning Initial Comment: On Python HEAD, there's a new warning while compiling bz2module.c (MSVC 7.1): python\Modules\bz2module.c(1095) : warning C4244: '=' : conversion from 'Py_off_t' to 'int', possible loss of data Looks like a legitimate complaint to me. The line in question: readsize = offset-bytesread; Those have types int, Py_off_t, and int respectively. Is it true that offset-bytesread _necessarily_ fits in an int? If so, a comment should explain why, and a cast should be added to squash the warning. Or If the difference doesn't necessarily fit in an int, the code is wrong. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 19:02 Message: Logged In: YES user_id=1188172 Tackled the two warnings (tell() should return a long int if 64 bits) with new patch. I can't see the error in your output. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-27 18:31 Message: Logged In: YES user_id=80475 The latest patch gives me the following: --------------------Configuration: bz2 - Win32 Debug-------------------- Compiling... bz2module.c C:\py25\Modules\bz2module.c(1143) : warning C4244: 'function' : conversion from '__int64 ' to 'long ', possible loss of data C:\py25\Modules\bz2module.c(1143) : warning C4761: integral size mismatch in argument; conversion supplied lib /out:libbz2.lib blocksort.obj huffman.obj crctable.obj randtable.obj compress.obj decompress.obj bzlib.obj Microsoft (R) Library Manager Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. cl -DWIN32 -MD -Ox -D_FILE_OFFSET_BITS=64 -nologo -o bzip2 bzip2.c libbz2.lib setargv.obj bzip2.c cl -DWIN32 -MD -Ox -D_FILE_OFFSET_BITS=64 -nologo -o bzip2recover bzip2recover.c bzip2recover.c type words1 Doing 6 tests (3 compress, 3 uncompress) ... If there's a problem, things might stop at this point. .\bzip2 -1 < sample1.ref > sample1.rb2 .\bzip2 -2 < sample2.ref > sample2.rb2 .\bzip2 -3 < sample3.ref > sample3.rb2 .\bzip2 -d < sample1.bz2 > sample1.tst .\bzip2 -d < sample2.bz2 > sample2.tst .\bzip2 -ds < sample3.bz2 > sample3.tst All six of the fc's should find no differences. If fc finds an error on sample3.bz2, this could be because WinZip's 'TAR file smart CR/LF conversion' is too clever for its own good. Disable this option. The correct size for sample3.ref is 120,244. If it is 150,251, WinZip has messed it up. fc sample1.bz2 sample1.rb2 Comparing files sample1.bz2 and sample1.rb2 FC: no differences encountered fc sample2.bz2 sample2.rb2 Comparing files sample2.bz2 and sample2.rb2 FC: no differences encountered fc sample3.bz2 sample3.rb2 Comparing files sample3.bz2 and sample3.rb2 ****** sample3.bz2 BZh31AY&SY??3? ??uU???`??2 ???I%@? ??????^??1 ????????????)????al?Dh3H???\mIL?hii??B?R? ****** sample3.rb2 BZh31AY&SY???> ?# ?A?J3?????z? ??7U?{??C2 ?l }??? ****** fc sample1.tst sample1.ref Comparing files sample1.tst and sample1.ref FC: no differences encountered fc sample2.tst sample2.ref Comparing files sample2.tst and sample2.ref FC: no differences encountered fc sample3.tst sample3.ref Comparing files sample3.tst and sample3.ref FC: no differences encountered Linking... bz2_d.pyd - 1 error(s), 2 warning(s) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 16:36 Message: Logged In: YES user_id=1188172 Okay, next try. Someone with Windows should check this before I check in. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-27 14:55 Message: Logged In: YES user_id=21627 As Tim says: the cast deserves a comment, explaining why it cannot overflow. Even when readsize is size_t, it might still overflow, since Py_off_t might be wider than size_t. Apart from that, the patch looks good - but I can't check whether it silences the warning on Windows. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 14:27 Message: Logged In: YES user_id=1188172 Attaching patch for f->pos and f->size as Py_off_t. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-27 12:30 Message: Logged In: YES user_id=21627 Clearly, the difference is bound by buffersize (since, if it is larger, readsize is set to buffersize). buffersize is initialized to SMALLCHUNK, which is 8192, and never changed, so yes, the difference fits to an int an all supported platforms. OTOH, the condition of the if statement is bogus: if ((size_t)offset-bytesread > buffersize) offset is of type Py_off_t, which is a 64-bit type on most platforms. Casting it to size_t causes truncation on 32-bit platforms. Furthermore, I think self->pos should be of type Py_off_t, as it will wrap around for files larger >2GB on 32-bit platforms; the same for self->size. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 17:05 Message: Logged In: YES user_id=1188172 I think declaring readsize as size_t should fix the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&group_id=5470 From noreply at sourceforge.net Sat Aug 27 19:13:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 27 Aug 2005 10:13:09 -0700 Subject: [ python-Bugs-1274069 ] bz2module.c compiler warning Message-ID: Bugs item #1274069, was opened at 2005-08-26 10:25 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: bz2module.c compiler warning Initial Comment: On Python HEAD, there's a new warning while compiling bz2module.c (MSVC 7.1): python\Modules\bz2module.c(1095) : warning C4244: '=' : conversion from 'Py_off_t' to 'int', possible loss of data Looks like a legitimate complaint to me. The line in question: readsize = offset-bytesread; Those have types int, Py_off_t, and int respectively. Is it true that offset-bytesread _necessarily_ fits in an int? If so, a comment should explain why, and a cast should be added to squash the warning. Or If the difference doesn't necessarily fit in an int, the code is wrong. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-08-27 13:13 Message: Logged In: YES user_id=31435 Raymond, did you read the error output and verify that you're not suffering from the sample3.bz2 problem it explains? """ All six of the fc's should find no differences. If fc finds an error on sample3.bz2, this could be because WinZip's 'TAR file smart CR/LF conversion' is too clever for its own good. Disable this option. The correct size for sample3.ref is 120,244. If it is 150,251, WinZip has messed it up. """ Since the error you saw did come from sample3.bz2, that would be a good thing to check ;-) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 13:02 Message: Logged In: YES user_id=1188172 Tackled the two warnings (tell() should return a long int if 64 bits) with new patch. I can't see the error in your output. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-27 12:31 Message: Logged In: YES user_id=80475 The latest patch gives me the following: --------------------Configuration: bz2 - Win32 Debug-------------------- Compiling... bz2module.c C:\py25\Modules\bz2module.c(1143) : warning C4244: 'function' : conversion from '__int64 ' to 'long ', possible loss of data C:\py25\Modules\bz2module.c(1143) : warning C4761: integral size mismatch in argument; conversion supplied lib /out:libbz2.lib blocksort.obj huffman.obj crctable.obj randtable.obj compress.obj decompress.obj bzlib.obj Microsoft (R) Library Manager Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. cl -DWIN32 -MD -Ox -D_FILE_OFFSET_BITS=64 -nologo -o bzip2 bzip2.c libbz2.lib setargv.obj bzip2.c cl -DWIN32 -MD -Ox -D_FILE_OFFSET_BITS=64 -nologo -o bzip2recover bzip2recover.c bzip2recover.c type words1 Doing 6 tests (3 compress, 3 uncompress) ... If there's a problem, things might stop at this point. .\bzip2 -1 < sample1.ref > sample1.rb2 .\bzip2 -2 < sample2.ref > sample2.rb2 .\bzip2 -3 < sample3.ref > sample3.rb2 .\bzip2 -d < sample1.bz2 > sample1.tst .\bzip2 -d < sample2.bz2 > sample2.tst .\bzip2 -ds < sample3.bz2 > sample3.tst All six of the fc's should find no differences. If fc finds an error on sample3.bz2, this could be because WinZip's 'TAR file smart CR/LF conversion' is too clever for its own good. Disable this option. The correct size for sample3.ref is 120,244. If it is 150,251, WinZip has messed it up. fc sample1.bz2 sample1.rb2 Comparing files sample1.bz2 and sample1.rb2 FC: no differences encountered fc sample2.bz2 sample2.rb2 Comparing files sample2.bz2 and sample2.rb2 FC: no differences encountered fc sample3.bz2 sample3.rb2 Comparing files sample3.bz2 and sample3.rb2 ****** sample3.bz2 BZh31AY&SY??3? ??uU???`??2 ???I%@? ??????^??1 ????????????)????al?Dh3H???\mIL?hii??B?R? ****** sample3.rb2 BZh31AY&SY???> ?# ?A?J3?????z? ??7U?{??C2 ?l }??? ****** fc sample1.tst sample1.ref Comparing files sample1.tst and sample1.ref FC: no differences encountered fc sample2.tst sample2.ref Comparing files sample2.tst and sample2.ref FC: no differences encountered fc sample3.tst sample3.ref Comparing files sample3.tst and sample3.ref FC: no differences encountered Linking... bz2_d.pyd - 1 error(s), 2 warning(s) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 10:36 Message: Logged In: YES user_id=1188172 Okay, next try. Someone with Windows should check this before I check in. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-27 08:55 Message: Logged In: YES user_id=21627 As Tim says: the cast deserves a comment, explaining why it cannot overflow. Even when readsize is size_t, it might still overflow, since Py_off_t might be wider than size_t. Apart from that, the patch looks good - but I can't check whether it silences the warning on Windows. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 08:27 Message: Logged In: YES user_id=1188172 Attaching patch for f->pos and f->size as Py_off_t. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-27 06:30 Message: Logged In: YES user_id=21627 Clearly, the difference is bound by buffersize (since, if it is larger, readsize is set to buffersize). buffersize is initialized to SMALLCHUNK, which is 8192, and never changed, so yes, the difference fits to an int an all supported platforms. OTOH, the condition of the if statement is bogus: if ((size_t)offset-bytesread > buffersize) offset is of type Py_off_t, which is a 64-bit type on most platforms. Casting it to size_t causes truncation on 32-bit platforms. Furthermore, I think self->pos should be of type Py_off_t, as it will wrap around for files larger >2GB on 32-bit platforms; the same for self->size. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 11:05 Message: Logged In: YES user_id=1188172 I think declaring readsize as size_t should fix the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&group_id=5470 From noreply at sourceforge.net Sat Aug 27 19:52:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 27 Aug 2005 10:52:29 -0700 Subject: [ python-Bugs-1274069 ] bz2module.c compiler warning Message-ID: Bugs item #1274069, was opened at 2005-08-26 09:25 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: bz2module.c compiler warning Initial Comment: On Python HEAD, there's a new warning while compiling bz2module.c (MSVC 7.1): python\Modules\bz2module.c(1095) : warning C4244: '=' : conversion from 'Py_off_t' to 'int', possible loss of data Looks like a legitimate complaint to me. The line in question: readsize = offset-bytesread; Those have types int, Py_off_t, and int respectively. Is it true that offset-bytesread _necessarily_ fits in an int? If so, a comment should explain why, and a cast should be added to squash the warning. Or If the difference doesn't necessarily fit in an int, the code is wrong. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-27 12:52 Message: Logged In: YES user_id=80475 The new patch works fine on this end. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-08-27 12:13 Message: Logged In: YES user_id=31435 Raymond, did you read the error output and verify that you're not suffering from the sample3.bz2 problem it explains? """ All six of the fc's should find no differences. If fc finds an error on sample3.bz2, this could be because WinZip's 'TAR file smart CR/LF conversion' is too clever for its own good. Disable this option. The correct size for sample3.ref is 120,244. If it is 150,251, WinZip has messed it up. """ Since the error you saw did come from sample3.bz2, that would be a good thing to check ;-) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 12:02 Message: Logged In: YES user_id=1188172 Tackled the two warnings (tell() should return a long int if 64 bits) with new patch. I can't see the error in your output. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-27 11:31 Message: Logged In: YES user_id=80475 The latest patch gives me the following: --------------------Configuration: bz2 - Win32 Debug-------------------- Compiling... bz2module.c C:\py25\Modules\bz2module.c(1143) : warning C4244: 'function' : conversion from '__int64 ' to 'long ', possible loss of data C:\py25\Modules\bz2module.c(1143) : warning C4761: integral size mismatch in argument; conversion supplied lib /out:libbz2.lib blocksort.obj huffman.obj crctable.obj randtable.obj compress.obj decompress.obj bzlib.obj Microsoft (R) Library Manager Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. cl -DWIN32 -MD -Ox -D_FILE_OFFSET_BITS=64 -nologo -o bzip2 bzip2.c libbz2.lib setargv.obj bzip2.c cl -DWIN32 -MD -Ox -D_FILE_OFFSET_BITS=64 -nologo -o bzip2recover bzip2recover.c bzip2recover.c type words1 Doing 6 tests (3 compress, 3 uncompress) ... If there's a problem, things might stop at this point. .\bzip2 -1 < sample1.ref > sample1.rb2 .\bzip2 -2 < sample2.ref > sample2.rb2 .\bzip2 -3 < sample3.ref > sample3.rb2 .\bzip2 -d < sample1.bz2 > sample1.tst .\bzip2 -d < sample2.bz2 > sample2.tst .\bzip2 -ds < sample3.bz2 > sample3.tst All six of the fc's should find no differences. If fc finds an error on sample3.bz2, this could be because WinZip's 'TAR file smart CR/LF conversion' is too clever for its own good. Disable this option. The correct size for sample3.ref is 120,244. If it is 150,251, WinZip has messed it up. fc sample1.bz2 sample1.rb2 Comparing files sample1.bz2 and sample1.rb2 FC: no differences encountered fc sample2.bz2 sample2.rb2 Comparing files sample2.bz2 and sample2.rb2 FC: no differences encountered fc sample3.bz2 sample3.rb2 Comparing files sample3.bz2 and sample3.rb2 ****** sample3.bz2 BZh31AY&SY??3? ??uU???`??2 ???I%@? ??????^??1 ????????????)????al?Dh3H???\mIL?hii??B?R? ****** sample3.rb2 BZh31AY&SY???> ?# ?A?J3?????z? ??7U?{??C2 ?l }??? ****** fc sample1.tst sample1.ref Comparing files sample1.tst and sample1.ref FC: no differences encountered fc sample2.tst sample2.ref Comparing files sample2.tst and sample2.ref FC: no differences encountered fc sample3.tst sample3.ref Comparing files sample3.tst and sample3.ref FC: no differences encountered Linking... bz2_d.pyd - 1 error(s), 2 warning(s) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 09:36 Message: Logged In: YES user_id=1188172 Okay, next try. Someone with Windows should check this before I check in. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-27 07:55 Message: Logged In: YES user_id=21627 As Tim says: the cast deserves a comment, explaining why it cannot overflow. Even when readsize is size_t, it might still overflow, since Py_off_t might be wider than size_t. Apart from that, the patch looks good - but I can't check whether it silences the warning on Windows. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-27 07:27 Message: Logged In: YES user_id=1188172 Attaching patch for f->pos and f->size as Py_off_t. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-27 05:30 Message: Logged In: YES user_id=21627 Clearly, the difference is bound by buffersize (since, if it is larger, readsize is set to buffersize). buffersize is initialized to SMALLCHUNK, which is 8192, and never changed, so yes, the difference fits to an int an all supported platforms. OTOH, the condition of the if statement is bogus: if ((size_t)offset-bytesread > buffersize) offset is of type Py_off_t, which is a 64-bit type on most platforms. Casting it to size_t causes truncation on 32-bit platforms. Furthermore, I think self->pos should be of type Py_off_t, as it will wrap around for files larger >2GB on 32-bit platforms; the same for self->size. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 10:05 Message: Logged In: YES user_id=1188172 I think declaring readsize as size_t should fix the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&group_id=5470 From noreply at sourceforge.net Sat Aug 27 23:40:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 27 Aug 2005 14:40:57 -0700 Subject: [ python-Bugs-1274828 ] splitunc not documented Message-ID: Bugs item #1274828, was opened at 2005-08-27 15:40 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=1274828&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: Poor Yorick (pooryorick) Assigned to: Nobody/Anonymous (nobody) Summary: splitunc not documented Initial Comment: a description of splitunc is missing from http://docs.python.org/lib/module-os.path.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274828&group_id=5470 From noreply at sourceforge.net Sun Aug 28 10:10:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 28 Aug 2005 01:10:07 -0700 Subject: [ python-Bugs-1244610 ] 2.4.1 build fails on OpenBSD 3.7 Message-ID: Bugs item #1244610, was opened at 2005-07-26 01:31 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&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: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 build fails on OpenBSD 3.7 Initial Comment: Python 2.4.1, OpenBSD 3.7, gcc (GCC) 3.3.5 (propolice). I'm including the logs here because they are short. "./configure" printed the following: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------------ ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ------------------------------------------------ ## checking for curses.h... yes This warning was printed for curses.h, ncurses.h, sys/audioio.h, and sys/lock.h. (The reference to "Autoconf documentation" is useless, because autoconf is not used during the configure process, and is not even installed on the system where I was doing the build.) Then: % make gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c In file included from /usr/include/sys/select.h:38, from Include/pyport.h:116, from Include/Python.h:55, from Modules/python.c:3: /usr/include/sys/event.h:53: error: syntax error before "u_int" /usr/include/sys/event.h:55: error: syntax error before "u_short" *** Error code 1 Stop in /usr/src/Python-2.4.1. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-08-28 17:10 Message: Logged In: YES user_id=55188 For curses.h problem, it doesn't harm the build much in fact. It's already reported to FreeBSD bugdb http://www.FreeBSD.org/cgi/query-pr.cgi?pr=84219 and I think it's identical problem on OpenBSD. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-10 03:40 Message: Logged In: YES user_id=21627 Can somebody attach a config.log, or reproduce the fragment that deals with the curses.h presence? Does your system require any headers to be included for curses.h to be usable? I.e. if you do #include int main(){} will that program compile, or do you need additional ('prerequisite') headers? ---------------------------------------------------------------------- Comment By: johnnie pittman (jp3g) Date: 2005-08-09 15:34 Message: Logged In: YES user_id=1203137 Hey folks, Also seeing this issue on 3.7. Same setup described above. Loewis, not sure about the first part of your comment. If your asking if those header files exist and are available, yes they are (atleast on my system). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-06 21:43 Message: Logged In: YES user_id=21627 So can you tell us whether there are missing prerequisite headers? One would need to have access to your operating system to resolve this issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 From noreply at sourceforge.net Sun Aug 28 10:15:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 28 Aug 2005 01:15:44 -0700 Subject: [ python-Bugs-1258986 ] Makefile ignores $CPPFLAGS Message-ID: Bugs item #1258986, was opened at 2005-08-14 22:11 Message generated for change (Settings changed) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258986&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: Build Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Dirk Pirschel (pirschel) Assigned to: Nobody/Anonymous (nobody) Summary: Makefile ignores $CPPFLAGS Initial Comment: Makefile ignores $CPPFLAGS Environment variable. Solution: patch Makefile.pre.in with ----- snip ----- 59c59 < CPPFLAGS= -I. -I$(srcdir)/Include --- > CPPFLAGS= -I. -I$(srcdir)/Include @CPPFLAGS@ ----- snip ----- ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-08-28 17:15 Message: Logged In: YES user_id=55188 It's already fixed in revision 1.149. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258986&group_id=5470 From noreply at sourceforge.net Sun Aug 28 13:02:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 28 Aug 2005 04:02:30 -0700 Subject: [ python-Bugs-864374 ] 2.3.3 tests on cygwin Message-ID: Bugs item #864374, was opened at 2003-12-22 13:30 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864374&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.3 tests on cygwin Initial Comment: Hello, After running ./configure --prefix=/usr make make test I get the following --- 217 tests OK. 7 tests failed: test_bz2 test_fork1 test_largefile test_os test_popen2 test_pty test_tempfile 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_dbm test_email_codecs test_gl test_imgfile test_ioctl test_linuxaudiodev test_locale test_macfs test_macostools test_mpz test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound Those skips are all expected on cygwin. When running test_bz2, test_fork1, test_popen2, test_pty, test_tempfile alone they look ok (return value to OS is 0). For the others I'm attaching output. My system is win2k on IBM T30 (laptop). Cygwin 1.5.5. Miki ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2005-08-28 14:02 Message: Logged In: YES user_id=358087 Sorry, due to some bizzar DLL relocation problems with cygwin I can't run the rull test suite. However test_bz2 fails *before* the test suite gets stuck ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 16:28 Message: Logged In: YES user_id=1188172 Can you verify this with 2.4.1 or a CVS version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864374&group_id=5470 From noreply at sourceforge.net Sun Aug 28 22:25:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 28 Aug 2005 13:25:00 -0700 Subject: [ python-Bugs-1234674 ] filecmp.cmp's "shallow" option Message-ID: Bugs item #1234674, was opened at 2005-07-08 11:01 Message generated for change (Comment added) made by pvrijlandt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234674&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: Mendez (goatsofmendez) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: filecmp.cmp's "shallow" option Initial Comment: The filecmp.cmp function has a shallow option (set as default) to only compare files based on stats rather than doing a bit by bit comparison of the file itself. The relevant bit of the code follows. s1 = _sig(os.stat(f1)) s2 = _sig(os.stat(f2)) if s1[0] != stat.S_IFREG or s2[0] != stat.S_IFREG: return False if shallow and s1 == s2: return True if s1[1] != s2[1]: return False result = _cache.get((f1, f2)) if result and (s1, s2) == result[:2]: return result[2] outcome = _do_cmp(f1, f2) _cache[f1, f2] = s1, s2, outcome return outcome There's a check to see if the shallow mode is enabled and if that's the case and the stats match it returns true but the test for returning false is for only one of the stats attributes meaning that it's possible for a file not to match either test and the function to carry on to the full file check lower down. The check above to see if the stats match with stat.S_IFREG also looks wrong to me, but it could just be I don't understand what he's trying to do :) This code is the same in both 2.3 and 2.4 ---------------------------------------------------------------------- Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2005-08-28 22:24 Message: Logged In: YES user_id=1307917 The cache is buggy too; it can be fooled by changing the cwd between calls. Also, if it caches (a, b) it does not cache (b, a). Is this caching feature really useful? Maybe it's up to the caller to record what comparisons have been made. If a caching function is to be provided, it should recognize the (b, a) case and maybe also infer from (a, b) and (b, c) about (a, c). (My programs remember an md5-signature) I propose to eliminate the caching feature. Also I propose to publish cmp_shallow and cmp_bytes which I think will make the unit easier to understand and verify. cmp_bytes is of course _do_cmp, with a check added for length equality. Then, the docs should be updated to whatever implementation for cmp is chosen, because non-shallow comparison is ill-specified. cmp should return a bool. what should cmp do with funny input like a dir? It now returns false. Would an exception be better? BTW: is it really useful in _do_cmp to have a local variable bufsize? is 8k still optimal? ---------------------------------------------------------------------- Comment By: Mendez (goatsofmendez) Date: 2005-08-26 13:38 Message: Logged In: YES user_id=1309441 On my own system I've modified the testing code as follows if s1 != s2: return False if shallow and s1 == s2: return True Which works as I expected it to work If attributes aren't identical - Always fails If the attributes are identical and it's in shallow mode - returns true If the attributes are identical and it's not in shallow mode - goes on to check if the files are byte identical. Whether there should be additional modes for finding byte identical files with different names, attributes etc. is another matter. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-26 10:33 Message: Logged In: YES user_id=80475 Fred, do you have thoughts on this patch? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 10:19 Message: Logged In: YES user_id=1188172 Hm. Looks like if the size is identical, but the mtime is not, the file will be read even in shallow mode. The filecmp docs say "Unless shallow is given and is false, files with identical os.stat() signatures are taken to be equal." The filecmp.cmp docstring says "shallow: Just check stat signature (do not read the files)" Two questions arise: - Should the file contents be compared in shallow mode if the mtimes do not match? - Should the mtimes matter in non-shallow mode? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234674&group_id=5470 From noreply at sourceforge.net Mon Aug 29 00:16:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 28 Aug 2005 15:16:09 -0700 Subject: [ python-Bugs-1234674 ] filecmp.cmp's "shallow" option Message-ID: Bugs item #1234674, was opened at 2005-07-08 11:01 Message generated for change (Comment added) made by pvrijlandt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234674&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: Mendez (goatsofmendez) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: filecmp.cmp's "shallow" option Initial Comment: The filecmp.cmp function has a shallow option (set as default) to only compare files based on stats rather than doing a bit by bit comparison of the file itself. The relevant bit of the code follows. s1 = _sig(os.stat(f1)) s2 = _sig(os.stat(f2)) if s1[0] != stat.S_IFREG or s2[0] != stat.S_IFREG: return False if shallow and s1 == s2: return True if s1[1] != s2[1]: return False result = _cache.get((f1, f2)) if result and (s1, s2) == result[:2]: return result[2] outcome = _do_cmp(f1, f2) _cache[f1, f2] = s1, s2, outcome return outcome There's a check to see if the shallow mode is enabled and if that's the case and the stats match it returns true but the test for returning false is for only one of the stats attributes meaning that it's possible for a file not to match either test and the function to carry on to the full file check lower down. The check above to see if the stats match with stat.S_IFREG also looks wrong to me, but it could just be I don't understand what he's trying to do :) This code is the same in both 2.3 and 2.4 ---------------------------------------------------------------------- Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2005-08-29 00:16 Message: Logged In: YES user_id=1307917 "cmp should return a bool" refers to the modules docstring. On other places, it does already. The default value for "shallow" should be a bool too. ---------------------------------------------------------------------- Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2005-08-28 22:24 Message: Logged In: YES user_id=1307917 The cache is buggy too; it can be fooled by changing the cwd between calls. Also, if it caches (a, b) it does not cache (b, a). Is this caching feature really useful? Maybe it's up to the caller to record what comparisons have been made. If a caching function is to be provided, it should recognize the (b, a) case and maybe also infer from (a, b) and (b, c) about (a, c). (My programs remember an md5-signature) I propose to eliminate the caching feature. Also I propose to publish cmp_shallow and cmp_bytes which I think will make the unit easier to understand and verify. cmp_bytes is of course _do_cmp, with a check added for length equality. Then, the docs should be updated to whatever implementation for cmp is chosen, because non-shallow comparison is ill-specified. cmp should return a bool. what should cmp do with funny input like a dir? It now returns false. Would an exception be better? BTW: is it really useful in _do_cmp to have a local variable bufsize? is 8k still optimal? ---------------------------------------------------------------------- Comment By: Mendez (goatsofmendez) Date: 2005-08-26 13:38 Message: Logged In: YES user_id=1309441 On my own system I've modified the testing code as follows if s1 != s2: return False if shallow and s1 == s2: return True Which works as I expected it to work If attributes aren't identical - Always fails If the attributes are identical and it's in shallow mode - returns true If the attributes are identical and it's not in shallow mode - goes on to check if the files are byte identical. Whether there should be additional modes for finding byte identical files with different names, attributes etc. is another matter. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-26 10:33 Message: Logged In: YES user_id=80475 Fred, do you have thoughts on this patch? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 10:19 Message: Logged In: YES user_id=1188172 Hm. Looks like if the size is identical, but the mtime is not, the file will be read even in shallow mode. The filecmp docs say "Unless shallow is given and is false, files with identical os.stat() signatures are taken to be equal." The filecmp.cmp docstring says "shallow: Just check stat signature (do not read the files)" Two questions arise: - Should the file contents be compared in shallow mode if the mtimes do not match? - Should the mtimes matter in non-shallow mode? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234674&group_id=5470 From noreply at sourceforge.net Mon Aug 29 12:30:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 29 Aug 2005 03:30:28 -0700 Subject: [ python-Bugs-1275608 ] dict key comparison swallows exceptions Message-ID: Bugs item #1275608, was opened at 2005-08-29 10:30 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=1275608&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: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Michael Hudson (mwh) Summary: dict key comparison swallows exceptions Initial Comment: This is an old one that has just biten again and cost a lot of debugging time again: the dict lookup function swallows all errors during key comparison. This is bad in itself, but if the current stack depth is just wrong then *any* comparison will raise a RuntimeError and lookup will pretend that the dictionary is essentially empty. The attached sample program shows this and crashes with a KeyError instead of a RuntimeError. While at the C level there is a basic compatibility problem involved (PyDict_GetItem() not allowed to raise any exception -- see http://thread.gmane.org/gmane.comp.python.devel/62427), I think it should be possible to improve the situation on the Python interface. Unless someone points me to something I missed, I plan to come up with a patch that changes the internal dict functions (including lookdict()) to let exceptions pass through, and have the exceptions swallowed only by the PyDict_*() API functions that require it. The possible (remote) incompatibility here is existing code relying on the exceptions being swallowed -- either Python code, or C code using PyObject_GetItem() or PyMapping_GetItemString(). Such code deserves to be shot down in my opinion. Assigned to mwh for his feedback (not because I want him to write the patch!). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275608&group_id=5470 From noreply at sourceforge.net Mon Aug 29 15:49:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 29 Aug 2005 06:49:36 -0700 Subject: [ python-Bugs-1275677 ] add a get() method to sets Message-ID: Bugs item #1275677, was opened at 2005-08-29 15: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=1275677&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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Nobody/Anonymous (nobody) Summary: add a get() method to sets Initial Comment: Hi, I would like to propose a new method for the builtin set objects. Currently we have a pop() method which pops an element from the set. What I often need, though, is a method that gets an arbitrary element without removing it (because adding / removing stuff is dealt with in another part of the program). Right now the simplest way to do that is : value = iter(my_set).next() There are two problems with this: 1. it's ugly and not very intuitive 2. it is not atomic; this means if another thread updates the set, I can get a "RuntimeError: dictionary changed size during iteration" (btw, the message is slightly wrong, it should be "set" instead of "dictionary") Although the first problem is rather minor (but annoying nevertheless), the second one is a real showstopper in some cases - yes, I did encounter it for real. There is a way to avoid the second problem : value = list(my_set)[0] But of course, not only it is still ugly, but it is also highly inefficient when the set is big. So in the end I am forced to use an explicit lock around the aforementioned construct (value = iter(my_set).next()) as well as around any other piece of code that can update the set from another thread. This is tedious and error-prone, and probably a bit inefficient. So for the bottom line: it would be in some cases very useful to have an atomic get() method in addition to the pop() method on sets. (it could probably be applied to frozensets and dicts too) The implementation would probably not be very difficult, since it's the same as pop() with the removal feature removed. ;) But I'm not familiar with the Python internals. What do you think ? Regards Antoine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275677&group_id=5470 From noreply at sourceforge.net Mon Aug 29 16:54:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 29 Aug 2005 07:54:09 -0700 Subject: [ python-Bugs-1275719 ] discrepancy between str.__cmp__ and unicode.__cmp__ Message-ID: Bugs item #1275719, was opened at 2005-08-29 16:54 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=1275719&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: Antoine Pitrou (pitrou) Assigned to: Nobody/Anonymous (nobody) Summary: discrepancy between str.__cmp__ and unicode.__cmp__ Initial Comment: I had the surprise, while wanted to use str.__cmp__ as the cmp argument to list.sort(), that it seems buggy compared to unicode.__cmp__, and that these methods seem implemented quite differently (they have a different type): $ python Python 2.4.1 (#2, Aug 25 2005, 18:20:57) [GCC 4.0.1 (4.0.1-2mdk for Mandriva Linux release 2006.0)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> unicode.__cmp__ >>> str.__cmp__ >>> u'a'.__cmp__(u'b') -1 >>> 'a'.__cmp__('b') Traceback (most recent call last): File "", line 1, in ? AttributeError: 'str' object has no attribute '__cmp__' >>> unicode.__cmp__(u'a', u'b') -1 >>> str.__cmp__('a', 'b') Traceback (most recent call last): File "", line 1, in ? TypeError: expected 1 arguments, got 2 Am I missing something ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275719&group_id=5470 From noreply at sourceforge.net Mon Aug 29 17:15:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 29 Aug 2005 08:15:42 -0700 Subject: [ python-Bugs-1275677 ] add a get() method to sets Message-ID: Bugs item #1275677, was opened at 2005-08-29 15:49 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275677&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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) >Assigned to: Raymond Hettinger (rhettinger) Summary: add a get() method to sets Initial Comment: Hi, I would like to propose a new method for the builtin set objects. Currently we have a pop() method which pops an element from the set. What I often need, though, is a method that gets an arbitrary element without removing it (because adding / removing stuff is dealt with in another part of the program). Right now the simplest way to do that is : value = iter(my_set).next() There are two problems with this: 1. it's ugly and not very intuitive 2. it is not atomic; this means if another thread updates the set, I can get a "RuntimeError: dictionary changed size during iteration" (btw, the message is slightly wrong, it should be "set" instead of "dictionary") Although the first problem is rather minor (but annoying nevertheless), the second one is a real showstopper in some cases - yes, I did encounter it for real. There is a way to avoid the second problem : value = list(my_set)[0] But of course, not only it is still ugly, but it is also highly inefficient when the set is big. So in the end I am forced to use an explicit lock around the aforementioned construct (value = iter(my_set).next()) as well as around any other piece of code that can update the set from another thread. This is tedious and error-prone, and probably a bit inefficient. So for the bottom line: it would be in some cases very useful to have an atomic get() method in addition to the pop() method on sets. (it could probably be applied to frozensets and dicts too) The implementation would probably not be very difficult, since it's the same as pop() with the removal feature removed. ;) But I'm not familiar with the Python internals. What do you think ? Regards Antoine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275677&group_id=5470 From noreply at sourceforge.net Mon Aug 29 17:16:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 29 Aug 2005 08:16:40 -0700 Subject: [ python-Bugs-1275719 ] discrepancy between str.__cmp__ and unicode.__cmp__ Message-ID: Bugs item #1275719, was opened at 2005-08-29 16:54 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275719&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: Antoine Pitrou (pitrou) Assigned to: Nobody/Anonymous (nobody) Summary: discrepancy between str.__cmp__ and unicode.__cmp__ Initial Comment: I had the surprise, while wanted to use str.__cmp__ as the cmp argument to list.sort(), that it seems buggy compared to unicode.__cmp__, and that these methods seem implemented quite differently (they have a different type): $ python Python 2.4.1 (#2, Aug 25 2005, 18:20:57) [GCC 4.0.1 (4.0.1-2mdk for Mandriva Linux release 2006.0)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> unicode.__cmp__ >>> str.__cmp__ >>> u'a'.__cmp__(u'b') -1 >>> 'a'.__cmp__('b') Traceback (most recent call last): File "", line 1, in ? AttributeError: 'str' object has no attribute '__cmp__' >>> unicode.__cmp__(u'a', u'b') -1 >>> str.__cmp__('a', 'b') Traceback (most recent call last): File "", line 1, in ? TypeError: expected 1 arguments, got 2 Am I missing something ? ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-29 17:16 Message: Logged In: YES user_id=1188172 String comparison is done with rich compare methods, namely __lt__, __le__, __gt__, __ge__ and __eq__, __ne__. Why str.__cmp__ exists and 'a'.__cmp__ does not, I cannot say. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275719&group_id=5470 From noreply at sourceforge.net Mon Aug 29 17:35:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 29 Aug 2005 08:35:21 -0700 Subject: [ python-Bugs-1275719 ] discrepancy between str.__cmp__ and unicode.__cmp__ Message-ID: Bugs item #1275719, was opened at 2005-08-29 16:54 Message generated for change (Comment added) made by pitrou You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275719&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: Antoine Pitrou (pitrou) Assigned to: Nobody/Anonymous (nobody) Summary: discrepancy between str.__cmp__ and unicode.__cmp__ Initial Comment: I had the surprise, while wanted to use str.__cmp__ as the cmp argument to list.sort(), that it seems buggy compared to unicode.__cmp__, and that these methods seem implemented quite differently (they have a different type): $ python Python 2.4.1 (#2, Aug 25 2005, 18:20:57) [GCC 4.0.1 (4.0.1-2mdk for Mandriva Linux release 2006.0)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> unicode.__cmp__ >>> str.__cmp__ >>> u'a'.__cmp__(u'b') -1 >>> 'a'.__cmp__('b') Traceback (most recent call last): File "", line 1, in ? AttributeError: 'str' object has no attribute '__cmp__' >>> unicode.__cmp__(u'a', u'b') -1 >>> str.__cmp__('a', 'b') Traceback (most recent call last): File "", line 1, in ? TypeError: expected 1 arguments, got 2 Am I missing something ? ---------------------------------------------------------------------- >Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 17:35 Message: Logged In: YES user_id=133955 You are right, I also forgot there is a builtin cmp() function that works like expected. Still str.__cmp__'s behaviour is a bit puzzling to me... ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-29 17:16 Message: Logged In: YES user_id=1188172 String comparison is done with rich compare methods, namely __lt__, __le__, __gt__, __ge__ and __eq__, __ne__. Why str.__cmp__ exists and 'a'.__cmp__ does not, I cannot say. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275719&group_id=5470 From noreply at sourceforge.net Mon Aug 29 19:10:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 29 Aug 2005 10:10:11 -0700 Subject: [ python-Feature Requests-1275677 ] add a get() method to sets Message-ID: Feature Requests item #1275677, was opened at 2005-08-29 08:49 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&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: None Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Raymond Hettinger (rhettinger) Summary: add a get() method to sets Initial Comment: Hi, I would like to propose a new method for the builtin set objects. Currently we have a pop() method which pops an element from the set. What I often need, though, is a method that gets an arbitrary element without removing it (because adding / removing stuff is dealt with in another part of the program). Right now the simplest way to do that is : value = iter(my_set).next() There are two problems with this: 1. it's ugly and not very intuitive 2. it is not atomic; this means if another thread updates the set, I can get a "RuntimeError: dictionary changed size during iteration" (btw, the message is slightly wrong, it should be "set" instead of "dictionary") Although the first problem is rather minor (but annoying nevertheless), the second one is a real showstopper in some cases - yes, I did encounter it for real. There is a way to avoid the second problem : value = list(my_set)[0] But of course, not only it is still ugly, but it is also highly inefficient when the set is big. So in the end I am forced to use an explicit lock around the aforementioned construct (value = iter(my_set).next()) as well as around any other piece of code that can update the set from another thread. This is tedious and error-prone, and probably a bit inefficient. So for the bottom line: it would be in some cases very useful to have an atomic get() method in addition to the pop() method on sets. (it could probably be applied to frozensets and dicts too) The implementation would probably not be very difficult, since it's the same as pop() with the removal feature removed. ;) But I'm not familiar with the Python internals. What do you think ? Regards Antoine. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-29 12:10 Message: Logged In: YES user_id=80475 We've looked at a choose() method a couple of times and rejected it. Since the method gets an arbitrary element, it might as well get the first one it sees. But that is of little use in a loop (when do you ever need to get the same object over and over again?). Also, a choose method() would need to raise a KeyError if the set if emtpy and/or provide a default argument like dict.get() does. This complicates the heck out of using it. Put the two together and the idea loses any charm. Also, for mutable sets, a better approach is to pop() elements from the set and add them back when you're done with them. I'm not too concerned about atomicity. For one, that is almost never a good guide to API design. Second, it is implementation dependent (i.e. no guarantees for PyPy or Jython). Three, it generally indicates a problem in your design (if the set could mutate smaller during a thread accessing the set, then you have a race condition where the set could shrink to zero or not). Four, the right way to deal with atomicity issues is to use locks or control access via Queue. I do understand that basic motivation (I have a set, now how do I a representative element) but find the proposal lacking. It just doesn't do much for us. BTW, please post your use case (in a condensed form that gets to the essentials of why you think this method is needed).. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470 From noreply at sourceforge.net Mon Aug 29 20:31:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 29 Aug 2005 11:31:35 -0700 Subject: [ python-Feature Requests-1275677 ] add a get() method to sets Message-ID: Feature Requests item #1275677, was opened at 2005-08-29 15:49 Message generated for change (Comment added) made by pitrou You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&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: None Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Raymond Hettinger (rhettinger) Summary: add a get() method to sets Initial Comment: Hi, I would like to propose a new method for the builtin set objects. Currently we have a pop() method which pops an element from the set. What I often need, though, is a method that gets an arbitrary element without removing it (because adding / removing stuff is dealt with in another part of the program). Right now the simplest way to do that is : value = iter(my_set).next() There are two problems with this: 1. it's ugly and not very intuitive 2. it is not atomic; this means if another thread updates the set, I can get a "RuntimeError: dictionary changed size during iteration" (btw, the message is slightly wrong, it should be "set" instead of "dictionary") Although the first problem is rather minor (but annoying nevertheless), the second one is a real showstopper in some cases - yes, I did encounter it for real. There is a way to avoid the second problem : value = list(my_set)[0] But of course, not only it is still ugly, but it is also highly inefficient when the set is big. So in the end I am forced to use an explicit lock around the aforementioned construct (value = iter(my_set).next()) as well as around any other piece of code that can update the set from another thread. This is tedious and error-prone, and probably a bit inefficient. So for the bottom line: it would be in some cases very useful to have an atomic get() method in addition to the pop() method on sets. (it could probably be applied to frozensets and dicts too) The implementation would probably not be very difficult, since it's the same as pop() with the removal feature removed. ;) But I'm not familiar with the Python internals. What do you think ? Regards Antoine. ---------------------------------------------------------------------- >Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 20:31 Message: Logged In: YES user_id=133955 Hi, Thanks for the detailed reply. So, atomicity cannot be guaranteed. I understand that (you might tell it to the Twisted folks by the way, because as far as I've seen some of their code relies on list operations being atomic in CPython ;-)). Remains the simplicity argument. As for the first objection: my set is mutated in the loop in ways that I cannot predict (because each element in the set points me in turn to a user-defined callback that will often alter the set ;-)). That explains why it *is* useful to get the "first" element repeatedly: the "first" element changes very often. As for the use case : I'm writing a small cooperative multithread package using generators (mostly for fun, but I'll be glad if it pleases others too): https://developer.berlios.de/projects/tasklets/ Scheduling is based on "wait objects": when a wait object becomes ready, it is added to the set of ready objects and the main loop takes an element from this set and asks it for one of the threads waiting on the object. It is the set I'm talking about ;) Sometimes the readiness of one of those objects can be changed from another thread (for now I'm using a helper thread for timers, and perhaps also for other things in the future - IO, wxWidgets integration, etc.). The main loop is in the Switcher.run() method towards the end of the following file: http://svn.berlios.de/viewcvs/tasklets/trunk/softlets/core.py?view=markup As you see, I actually do a "for" on the set, but I always break of the "for" loop after the first iteration... Which is not very elegant and understandable for the reader. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-29 19:10 Message: Logged In: YES user_id=80475 We've looked at a choose() method a couple of times and rejected it. Since the method gets an arbitrary element, it might as well get the first one it sees. But that is of little use in a loop (when do you ever need to get the same object over and over again?). Also, a choose method() would need to raise a KeyError if the set if emtpy and/or provide a default argument like dict.get() does. This complicates the heck out of using it. Put the two together and the idea loses any charm. Also, for mutable sets, a better approach is to pop() elements from the set and add them back when you're done with them. I'm not too concerned about atomicity. For one, that is almost never a good guide to API design. Second, it is implementation dependent (i.e. no guarantees for PyPy or Jython). Three, it generally indicates a problem in your design (if the set could mutate smaller during a thread accessing the set, then you have a race condition where the set could shrink to zero or not). Four, the right way to deal with atomicity issues is to use locks or control access via Queue. I do understand that basic motivation (I have a set, now how do I a representative element) but find the proposal lacking. It just doesn't do much for us. BTW, please post your use case (in a condensed form that gets to the essentials of why you think this method is needed).. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470 From noreply at sourceforge.net Mon Aug 29 21:07:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 29 Aug 2005 12:07:11 -0700 Subject: [ python-Feature Requests-1275677 ] add a get() method to sets Message-ID: Feature Requests item #1275677, was opened at 2005-08-29 09:49 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&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: None Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Raymond Hettinger (rhettinger) Summary: add a get() method to sets Initial Comment: Hi, I would like to propose a new method for the builtin set objects. Currently we have a pop() method which pops an element from the set. What I often need, though, is a method that gets an arbitrary element without removing it (because adding / removing stuff is dealt with in another part of the program). Right now the simplest way to do that is : value = iter(my_set).next() There are two problems with this: 1. it's ugly and not very intuitive 2. it is not atomic; this means if another thread updates the set, I can get a "RuntimeError: dictionary changed size during iteration" (btw, the message is slightly wrong, it should be "set" instead of "dictionary") Although the first problem is rather minor (but annoying nevertheless), the second one is a real showstopper in some cases - yes, I did encounter it for real. There is a way to avoid the second problem : value = list(my_set)[0] But of course, not only it is still ugly, but it is also highly inefficient when the set is big. So in the end I am forced to use an explicit lock around the aforementioned construct (value = iter(my_set).next()) as well as around any other piece of code that can update the set from another thread. This is tedious and error-prone, and probably a bit inefficient. So for the bottom line: it would be in some cases very useful to have an atomic get() method in addition to the pop() method on sets. (it could probably be applied to frozensets and dicts too) The implementation would probably not be very difficult, since it's the same as pop() with the removal feature removed. ;) But I'm not familiar with the Python internals. What do you think ? Regards Antoine. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-08-29 15:07 Message: Logged In: YES user_id=764593 This does look like pop might be a better choice. When choosing a ready object, you pop it to unready because you're using it -- put it back in if the current use won't cause blocking, or when that use finishes. When choosing a waiting ready thread, either the thread is no longer ready (so put it back in waiting, but you don't want it in ready), or it runs (so it should no longer be in waiting). ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 14:31 Message: Logged In: YES user_id=133955 Hi, Thanks for the detailed reply. So, atomicity cannot be guaranteed. I understand that (you might tell it to the Twisted folks by the way, because as far as I've seen some of their code relies on list operations being atomic in CPython ;-)). Remains the simplicity argument. As for the first objection: my set is mutated in the loop in ways that I cannot predict (because each element in the set points me in turn to a user-defined callback that will often alter the set ;-)). That explains why it *is* useful to get the "first" element repeatedly: the "first" element changes very often. As for the use case : I'm writing a small cooperative multithread package using generators (mostly for fun, but I'll be glad if it pleases others too): https://developer.berlios.de/projects/tasklets/ Scheduling is based on "wait objects": when a wait object becomes ready, it is added to the set of ready objects and the main loop takes an element from this set and asks it for one of the threads waiting on the object. It is the set I'm talking about ;) Sometimes the readiness of one of those objects can be changed from another thread (for now I'm using a helper thread for timers, and perhaps also for other things in the future - IO, wxWidgets integration, etc.). The main loop is in the Switcher.run() method towards the end of the following file: http://svn.berlios.de/viewcvs/tasklets/trunk/softlets/core.py?view=markup As you see, I actually do a "for" on the set, but I always break of the "for" loop after the first iteration... Which is not very elegant and understandable for the reader. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-29 13:10 Message: Logged In: YES user_id=80475 We've looked at a choose() method a couple of times and rejected it. Since the method gets an arbitrary element, it might as well get the first one it sees. But that is of little use in a loop (when do you ever need to get the same object over and over again?). Also, a choose method() would need to raise a KeyError if the set if emtpy and/or provide a default argument like dict.get() does. This complicates the heck out of using it. Put the two together and the idea loses any charm. Also, for mutable sets, a better approach is to pop() elements from the set and add them back when you're done with them. I'm not too concerned about atomicity. For one, that is almost never a good guide to API design. Second, it is implementation dependent (i.e. no guarantees for PyPy or Jython). Three, it generally indicates a problem in your design (if the set could mutate smaller during a thread accessing the set, then you have a race condition where the set could shrink to zero or not). Four, the right way to deal with atomicity issues is to use locks or control access via Queue. I do understand that basic motivation (I have a set, now how do I a representative element) but find the proposal lacking. It just doesn't do much for us. BTW, please post your use case (in a condensed form that gets to the essentials of why you think this method is needed).. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470 From noreply at sourceforge.net Mon Aug 29 21:16:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 29 Aug 2005 12:16:29 -0700 Subject: [ python-Feature Requests-1275677 ] add a get() method to sets Message-ID: Feature Requests item #1275677, was opened at 2005-08-29 15:49 Message generated for change (Comment added) made by pitrou You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&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: None Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Raymond Hettinger (rhettinger) Summary: add a get() method to sets Initial Comment: Hi, I would like to propose a new method for the builtin set objects. Currently we have a pop() method which pops an element from the set. What I often need, though, is a method that gets an arbitrary element without removing it (because adding / removing stuff is dealt with in another part of the program). Right now the simplest way to do that is : value = iter(my_set).next() There are two problems with this: 1. it's ugly and not very intuitive 2. it is not atomic; this means if another thread updates the set, I can get a "RuntimeError: dictionary changed size during iteration" (btw, the message is slightly wrong, it should be "set" instead of "dictionary") Although the first problem is rather minor (but annoying nevertheless), the second one is a real showstopper in some cases - yes, I did encounter it for real. There is a way to avoid the second problem : value = list(my_set)[0] But of course, not only it is still ugly, but it is also highly inefficient when the set is big. So in the end I am forced to use an explicit lock around the aforementioned construct (value = iter(my_set).next()) as well as around any other piece of code that can update the set from another thread. This is tedious and error-prone, and probably a bit inefficient. So for the bottom line: it would be in some cases very useful to have an atomic get() method in addition to the pop() method on sets. (it could probably be applied to frozensets and dicts too) The implementation would probably not be very difficult, since it's the same as pop() with the removal feature removed. ;) But I'm not familiar with the Python internals. What do you think ? Regards Antoine. ---------------------------------------------------------------------- >Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 21:16 Message: Logged In: YES user_id=133955 > When choosing a ready object, you pop it to unready > because you're using it -- put it back in if the current use > won't cause blocking, or when that use finishes. That's not exactly my semantics (objects remain ready until they explicitly tell the contrary: for example a queue remains ready until it becomes empty), but I can live with a pop() / add() sequence provided it is efficient. Is it ? Otherwise I may go for "elem = iter(my_set).next()". Thanks for the very prompt answers, btw :) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-08-29 21:07 Message: Logged In: YES user_id=764593 This does look like pop might be a better choice. When choosing a ready object, you pop it to unready because you're using it -- put it back in if the current use won't cause blocking, or when that use finishes. When choosing a waiting ready thread, either the thread is no longer ready (so put it back in waiting, but you don't want it in ready), or it runs (so it should no longer be in waiting). ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 20:31 Message: Logged In: YES user_id=133955 Hi, Thanks for the detailed reply. So, atomicity cannot be guaranteed. I understand that (you might tell it to the Twisted folks by the way, because as far as I've seen some of their code relies on list operations being atomic in CPython ;-)). Remains the simplicity argument. As for the first objection: my set is mutated in the loop in ways that I cannot predict (because each element in the set points me in turn to a user-defined callback that will often alter the set ;-)). That explains why it *is* useful to get the "first" element repeatedly: the "first" element changes very often. As for the use case : I'm writing a small cooperative multithread package using generators (mostly for fun, but I'll be glad if it pleases others too): https://developer.berlios.de/projects/tasklets/ Scheduling is based on "wait objects": when a wait object becomes ready, it is added to the set of ready objects and the main loop takes an element from this set and asks it for one of the threads waiting on the object. It is the set I'm talking about ;) Sometimes the readiness of one of those objects can be changed from another thread (for now I'm using a helper thread for timers, and perhaps also for other things in the future - IO, wxWidgets integration, etc.). The main loop is in the Switcher.run() method towards the end of the following file: http://svn.berlios.de/viewcvs/tasklets/trunk/softlets/core.py?view=markup As you see, I actually do a "for" on the set, but I always break of the "for" loop after the first iteration... Which is not very elegant and understandable for the reader. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-29 19:10 Message: Logged In: YES user_id=80475 We've looked at a choose() method a couple of times and rejected it. Since the method gets an arbitrary element, it might as well get the first one it sees. But that is of little use in a loop (when do you ever need to get the same object over and over again?). Also, a choose method() would need to raise a KeyError if the set if emtpy and/or provide a default argument like dict.get() does. This complicates the heck out of using it. Put the two together and the idea loses any charm. Also, for mutable sets, a better approach is to pop() elements from the set and add them back when you're done with them. I'm not too concerned about atomicity. For one, that is almost never a good guide to API design. Second, it is implementation dependent (i.e. no guarantees for PyPy or Jython). Three, it generally indicates a problem in your design (if the set could mutate smaller during a thread accessing the set, then you have a race condition where the set could shrink to zero or not). Four, the right way to deal with atomicity issues is to use locks or control access via Queue. I do understand that basic motivation (I have a set, now how do I a representative element) but find the proposal lacking. It just doesn't do much for us. BTW, please post your use case (in a condensed form that gets to the essentials of why you think this method is needed).. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470 From noreply at sourceforge.net Mon Aug 29 22:42:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 29 Aug 2005 13:42:55 -0700 Subject: [ python-Feature Requests-1275677 ] add a get() method to sets Message-ID: Feature Requests item #1275677, was opened at 2005-08-29 14:49 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&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: None Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Raymond Hettinger (rhettinger) Summary: add a get() method to sets Initial Comment: Hi, I would like to propose a new method for the builtin set objects. Currently we have a pop() method which pops an element from the set. What I often need, though, is a method that gets an arbitrary element without removing it (because adding / removing stuff is dealt with in another part of the program). Right now the simplest way to do that is : value = iter(my_set).next() There are two problems with this: 1. it's ugly and not very intuitive 2. it is not atomic; this means if another thread updates the set, I can get a "RuntimeError: dictionary changed size during iteration" (btw, the message is slightly wrong, it should be "set" instead of "dictionary") Although the first problem is rather minor (but annoying nevertheless), the second one is a real showstopper in some cases - yes, I did encounter it for real. There is a way to avoid the second problem : value = list(my_set)[0] But of course, not only it is still ugly, but it is also highly inefficient when the set is big. So in the end I am forced to use an explicit lock around the aforementioned construct (value = iter(my_set).next()) as well as around any other piece of code that can update the set from another thread. This is tedious and error-prone, and probably a bit inefficient. So for the bottom line: it would be in some cases very useful to have an atomic get() method in addition to the pop() method on sets. (it could probably be applied to frozensets and dicts too) The implementation would probably not be very difficult, since it's the same as pop() with the removal feature removed. ;) But I'm not familiar with the Python internals. What do you think ? Regards Antoine. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-08-29 21:42 Message: Logged In: YES user_id=6656 _My_ use case for something like this is applying a series of constraints as set intersections until the set has one element; then I want to know what that element *is*. I could probably use .pop(), but it feels wrong, and I know I can (and indeed do) do iter(theSet).next() but that's obscure. ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 20:16 Message: Logged In: YES user_id=133955 > When choosing a ready object, you pop it to unready > because you're using it -- put it back in if the current use > won't cause blocking, or when that use finishes. That's not exactly my semantics (objects remain ready until they explicitly tell the contrary: for example a queue remains ready until it becomes empty), but I can live with a pop() / add() sequence provided it is efficient. Is it ? Otherwise I may go for "elem = iter(my_set).next()". Thanks for the very prompt answers, btw :) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-08-29 20:07 Message: Logged In: YES user_id=764593 This does look like pop might be a better choice. When choosing a ready object, you pop it to unready because you're using it -- put it back in if the current use won't cause blocking, or when that use finishes. When choosing a waiting ready thread, either the thread is no longer ready (so put it back in waiting, but you don't want it in ready), or it runs (so it should no longer be in waiting). ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 19:31 Message: Logged In: YES user_id=133955 Hi, Thanks for the detailed reply. So, atomicity cannot be guaranteed. I understand that (you might tell it to the Twisted folks by the way, because as far as I've seen some of their code relies on list operations being atomic in CPython ;-)). Remains the simplicity argument. As for the first objection: my set is mutated in the loop in ways that I cannot predict (because each element in the set points me in turn to a user-defined callback that will often alter the set ;-)). That explains why it *is* useful to get the "first" element repeatedly: the "first" element changes very often. As for the use case : I'm writing a small cooperative multithread package using generators (mostly for fun, but I'll be glad if it pleases others too): https://developer.berlios.de/projects/tasklets/ Scheduling is based on "wait objects": when a wait object becomes ready, it is added to the set of ready objects and the main loop takes an element from this set and asks it for one of the threads waiting on the object. It is the set I'm talking about ;) Sometimes the readiness of one of those objects can be changed from another thread (for now I'm using a helper thread for timers, and perhaps also for other things in the future - IO, wxWidgets integration, etc.). The main loop is in the Switcher.run() method towards the end of the following file: http://svn.berlios.de/viewcvs/tasklets/trunk/softlets/core.py?view=markup As you see, I actually do a "for" on the set, but I always break of the "for" loop after the first iteration... Which is not very elegant and understandable for the reader. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-29 18:10 Message: Logged In: YES user_id=80475 We've looked at a choose() method a couple of times and rejected it. Since the method gets an arbitrary element, it might as well get the first one it sees. But that is of little use in a loop (when do you ever need to get the same object over and over again?). Also, a choose method() would need to raise a KeyError if the set if emtpy and/or provide a default argument like dict.get() does. This complicates the heck out of using it. Put the two together and the idea loses any charm. Also, for mutable sets, a better approach is to pop() elements from the set and add them back when you're done with them. I'm not too concerned about atomicity. For one, that is almost never a good guide to API design. Second, it is implementation dependent (i.e. no guarantees for PyPy or Jython). Three, it generally indicates a problem in your design (if the set could mutate smaller during a thread accessing the set, then you have a race condition where the set could shrink to zero or not). Four, the right way to deal with atomicity issues is to use locks or control access via Queue. I do understand that basic motivation (I have a set, now how do I a representative element) but find the proposal lacking. It just doesn't do much for us. BTW, please post your use case (in a condensed form that gets to the essentials of why you think this method is needed).. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470 From noreply at sourceforge.net Tue Aug 30 00:30:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 29 Aug 2005 15:30:25 -0700 Subject: [ python-Feature Requests-1275677 ] add a get() method to sets Message-ID: Feature Requests item #1275677, was opened at 2005-08-29 08:49 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&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: None Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Raymond Hettinger (rhettinger) Summary: add a get() method to sets Initial Comment: Hi, I would like to propose a new method for the builtin set objects. Currently we have a pop() method which pops an element from the set. What I often need, though, is a method that gets an arbitrary element without removing it (because adding / removing stuff is dealt with in another part of the program). Right now the simplest way to do that is : value = iter(my_set).next() There are two problems with this: 1. it's ugly and not very intuitive 2. it is not atomic; this means if another thread updates the set, I can get a "RuntimeError: dictionary changed size during iteration" (btw, the message is slightly wrong, it should be "set" instead of "dictionary") Although the first problem is rather minor (but annoying nevertheless), the second one is a real showstopper in some cases - yes, I did encounter it for real. There is a way to avoid the second problem : value = list(my_set)[0] But of course, not only it is still ugly, but it is also highly inefficient when the set is big. So in the end I am forced to use an explicit lock around the aforementioned construct (value = iter(my_set).next()) as well as around any other piece of code that can update the set from another thread. This is tedious and error-prone, and probably a bit inefficient. So for the bottom line: it would be in some cases very useful to have an atomic get() method in addition to the pop() method on sets. (it could probably be applied to frozensets and dicts too) The implementation would probably not be very difficult, since it's the same as pop() with the removal feature removed. ;) But I'm not familiar with the Python internals. What do you think ? Regards Antoine. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-29 17:30 Message: Logged In: YES user_id=80475 Exploratory questions: Michael, if you know there is only one element in a set, do you really need a custom method just to extract it? There are so many other ways. Given s=set([7]): 1) x = list(s)[0] 2) x = s.pop() 3) x, = s 4) x = max(s) yada yada yada Antoine, yes a pop()/add() combination is efficient. IMO, it also clear in intent, easy to write, flexible enough for a variety of applications, the pop() is atomic, and the approach also works with other mutable containers (dicts, lists, deques). Question for Antoine: Have you ever had this need with other containers? For instance, how do you find an arbitrary key in a dictionary without popping, iterating, or listing it? Question for everyone: Since choose() would not be a mutating method, it would also apply to frozensets. Does it have any use there? Any appearance in a loop would be farce since it would always return the same value (the frozenset never mutates). Question for everyone: Is there any known application for choose() that isn't met by pop()/add() irrespective of whether it "feels right"? For applications other than Michael's, we won't know the size of the set in advance. Are there any examples of using choose() that won't have to have ugly EAFP or LBYL code to handle the case where the set is empty? Rather than a method just for sets, is it a more appropriate solution to have a generic function that takes any iterable and returns its first element: def getfirst(it): for elem in it: return elem raise ValueError('iterator is empty') A function like this would work with almost anything: first(dict(a=1, b=2)) first(set([1, 2])) first([1,2]) first(open('myfile.txt')) . . . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-08-29 15:42 Message: Logged In: YES user_id=6656 _My_ use case for something like this is applying a series of constraints as set intersections until the set has one element; then I want to know what that element *is*. I could probably use .pop(), but it feels wrong, and I know I can (and indeed do) do iter(theSet).next() but that's obscure. ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 14:16 Message: Logged In: YES user_id=133955 > When choosing a ready object, you pop it to unready > because you're using it -- put it back in if the current use > won't cause blocking, or when that use finishes. That's not exactly my semantics (objects remain ready until they explicitly tell the contrary: for example a queue remains ready until it becomes empty), but I can live with a pop() / add() sequence provided it is efficient. Is it ? Otherwise I may go for "elem = iter(my_set).next()". Thanks for the very prompt answers, btw :) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-08-29 14:07 Message: Logged In: YES user_id=764593 This does look like pop might be a better choice. When choosing a ready object, you pop it to unready because you're using it -- put it back in if the current use won't cause blocking, or when that use finishes. When choosing a waiting ready thread, either the thread is no longer ready (so put it back in waiting, but you don't want it in ready), or it runs (so it should no longer be in waiting). ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 13:31 Message: Logged In: YES user_id=133955 Hi, Thanks for the detailed reply. So, atomicity cannot be guaranteed. I understand that (you might tell it to the Twisted folks by the way, because as far as I've seen some of their code relies on list operations being atomic in CPython ;-)). Remains the simplicity argument. As for the first objection: my set is mutated in the loop in ways that I cannot predict (because each element in the set points me in turn to a user-defined callback that will often alter the set ;-)). That explains why it *is* useful to get the "first" element repeatedly: the "first" element changes very often. As for the use case : I'm writing a small cooperative multithread package using generators (mostly for fun, but I'll be glad if it pleases others too): https://developer.berlios.de/projects/tasklets/ Scheduling is based on "wait objects": when a wait object becomes ready, it is added to the set of ready objects and the main loop takes an element from this set and asks it for one of the threads waiting on the object. It is the set I'm talking about ;) Sometimes the readiness of one of those objects can be changed from another thread (for now I'm using a helper thread for timers, and perhaps also for other things in the future - IO, wxWidgets integration, etc.). The main loop is in the Switcher.run() method towards the end of the following file: http://svn.berlios.de/viewcvs/tasklets/trunk/softlets/core.py?view=markup As you see, I actually do a "for" on the set, but I always break of the "for" loop after the first iteration... Which is not very elegant and understandable for the reader. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-29 12:10 Message: Logged In: YES user_id=80475 We've looked at a choose() method a couple of times and rejected it. Since the method gets an arbitrary element, it might as well get the first one it sees. But that is of little use in a loop (when do you ever need to get the same object over and over again?). Also, a choose method() would need to raise a KeyError if the set if emtpy and/or provide a default argument like dict.get() does. This complicates the heck out of using it. Put the two together and the idea loses any charm. Also, for mutable sets, a better approach is to pop() elements from the set and add them back when you're done with them. I'm not too concerned about atomicity. For one, that is almost never a good guide to API design. Second, it is implementation dependent (i.e. no guarantees for PyPy or Jython). Three, it generally indicates a problem in your design (if the set could mutate smaller during a thread accessing the set, then you have a race condition where the set could shrink to zero or not). Four, the right way to deal with atomicity issues is to use locks or control access via Queue. I do understand that basic motivation (I have a set, now how do I a representative element) but find the proposal lacking. It just doesn't do much for us. BTW, please post your use case (in a condensed form that gets to the essentials of why you think this method is needed).. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470 From noreply at sourceforge.net Tue Aug 30 01:09:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 29 Aug 2005 16:09:18 -0700 Subject: [ python-Feature Requests-1275677 ] add a get() method to sets Message-ID: Feature Requests item #1275677, was opened at 2005-08-29 15:49 Message generated for change (Comment added) made by pitrou You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&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: None Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Raymond Hettinger (rhettinger) Summary: add a get() method to sets Initial Comment: Hi, I would like to propose a new method for the builtin set objects. Currently we have a pop() method which pops an element from the set. What I often need, though, is a method that gets an arbitrary element without removing it (because adding / removing stuff is dealt with in another part of the program). Right now the simplest way to do that is : value = iter(my_set).next() There are two problems with this: 1. it's ugly and not very intuitive 2. it is not atomic; this means if another thread updates the set, I can get a "RuntimeError: dictionary changed size during iteration" (btw, the message is slightly wrong, it should be "set" instead of "dictionary") Although the first problem is rather minor (but annoying nevertheless), the second one is a real showstopper in some cases - yes, I did encounter it for real. There is a way to avoid the second problem : value = list(my_set)[0] But of course, not only it is still ugly, but it is also highly inefficient when the set is big. So in the end I am forced to use an explicit lock around the aforementioned construct (value = iter(my_set).next()) as well as around any other piece of code that can update the set from another thread. This is tedious and error-prone, and probably a bit inefficient. So for the bottom line: it would be in some cases very useful to have an atomic get() method in addition to the pop() method on sets. (it could probably be applied to frozensets and dicts too) The implementation would probably not be very difficult, since it's the same as pop() with the removal feature removed. ;) But I'm not familiar with the Python internals. What do you think ? Regards Antoine. ---------------------------------------------------------------------- >Comment By: Antoine Pitrou (pitrou) Date: 2005-08-30 01:09 Message: Logged In: YES user_id=133955 Hi again, > Antoine, yes a pop()/add() combination is efficient. Ok, thanks. > IMO, > it also clear in intent, easy to write, flexible enough for > a variety of applications, the pop() is atomic, Small correction: the pop() is atomic, but the pop/add sequence is not, AFAIU ;) > Question for Antoine: Have you ever had this need with > other containers? I think I had it for a dict sometime. For lists and tuples, you can just use my_container[0] of course. But sets are often used differently than dicts IMHO. Dicts are mappings: you give a precise key and get the exact value associated with it. Sets are bags: sometimes you just want to pick an item, as you would do in a real bag, without looking inside to choose a specific item. > Since choose() would not be a > mutating method, it would also apply to frozensets. Does it > have any use there? Any appearance in a loop would be farce > since it would always return the same value (the frozenset > never mutates). The variable to which you apply the method call could reference another frozenset on the next loop iteration... Yes, it doesn't sound very frequent. > Question for everyone: Is there any known application for > choose() that isn't met by pop()/add() irrespective of > whether it "feels right"? I don't think so indeed. (it would be the case if the API guaranteed atomicity in the case of single bultin method calls like choose()) > For applications other than Michael's, we won't know the > size of the set in advance. Are there any examples of using > choose() that won't have to have ugly EAFP or LBYL code to > handle the case where the set is empty? First, sometimes you know the set is non-empty without knowing its size in advance (for example you are inside a big block beginning with "if len(my_set)"). Second, error catching is still needed with other alternatives (you either have to catch KeyError when doing s.pop(), or StopIteration when doing iter(s).next()). > Rather than a method just for sets, is it a more appropriate > solution to have a generic function that takes any iterable > and returns its first element: Well, I thought global builtin functions were less favoured than methods. But this doesn't sound stupid. On the other hand, generic functions are less easy to find about (usually if I want to have the set API, I type help(set) in a Python shell which I always have open. But there is no quick way to have a list of the builtin functions that can apply to iterables (*)). In my experience, I often forget about the generic builtin functions that come with Python - maybe that's just me. (*) if there was a base type "iterable" with the generic method first() defined on it, as well as some of the other functions defined in the itertools module, it would probably be more elegant and more frequently used. Anyway, if the concern with builtin types is to avoid bloating the API, then I admit that it's a fair concern and that the motivation to add the choose() method might indeed not be convincing enough. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-30 00:30 Message: Logged In: YES user_id=80475 Exploratory questions: Michael, if you know there is only one element in a set, do you really need a custom method just to extract it? There are so many other ways. Given s=set([7]): 1) x = list(s)[0] 2) x = s.pop() 3) x, = s 4) x = max(s) yada yada yada Antoine, yes a pop()/add() combination is efficient. IMO, it also clear in intent, easy to write, flexible enough for a variety of applications, the pop() is atomic, and the approach also works with other mutable containers (dicts, lists, deques). Question for Antoine: Have you ever had this need with other containers? For instance, how do you find an arbitrary key in a dictionary without popping, iterating, or listing it? Question for everyone: Since choose() would not be a mutating method, it would also apply to frozensets. Does it have any use there? Any appearance in a loop would be farce since it would always return the same value (the frozenset never mutates). Question for everyone: Is there any known application for choose() that isn't met by pop()/add() irrespective of whether it "feels right"? For applications other than Michael's, we won't know the size of the set in advance. Are there any examples of using choose() that won't have to have ugly EAFP or LBYL code to handle the case where the set is empty? Rather than a method just for sets, is it a more appropriate solution to have a generic function that takes any iterable and returns its first element: def getfirst(it): for elem in it: return elem raise ValueError('iterator is empty') A function like this would work with almost anything: first(dict(a=1, b=2)) first(set([1, 2])) first([1,2]) first(open('myfile.txt')) . . . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-08-29 22:42 Message: Logged In: YES user_id=6656 _My_ use case for something like this is applying a series of constraints as set intersections until the set has one element; then I want to know what that element *is*. I could probably use .pop(), but it feels wrong, and I know I can (and indeed do) do iter(theSet).next() but that's obscure. ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 21:16 Message: Logged In: YES user_id=133955 > When choosing a ready object, you pop it to unready > because you're using it -- put it back in if the current use > won't cause blocking, or when that use finishes. That's not exactly my semantics (objects remain ready until they explicitly tell the contrary: for example a queue remains ready until it becomes empty), but I can live with a pop() / add() sequence provided it is efficient. Is it ? Otherwise I may go for "elem = iter(my_set).next()". Thanks for the very prompt answers, btw :) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-08-29 21:07 Message: Logged In: YES user_id=764593 This does look like pop might be a better choice. When choosing a ready object, you pop it to unready because you're using it -- put it back in if the current use won't cause blocking, or when that use finishes. When choosing a waiting ready thread, either the thread is no longer ready (so put it back in waiting, but you don't want it in ready), or it runs (so it should no longer be in waiting). ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 20:31 Message: Logged In: YES user_id=133955 Hi, Thanks for the detailed reply. So, atomicity cannot be guaranteed. I understand that (you might tell it to the Twisted folks by the way, because as far as I've seen some of their code relies on list operations being atomic in CPython ;-)). Remains the simplicity argument. As for the first objection: my set is mutated in the loop in ways that I cannot predict (because each element in the set points me in turn to a user-defined callback that will often alter the set ;-)). That explains why it *is* useful to get the "first" element repeatedly: the "first" element changes very often. As for the use case : I'm writing a small cooperative multithread package using generators (mostly for fun, but I'll be glad if it pleases others too): https://developer.berlios.de/projects/tasklets/ Scheduling is based on "wait objects": when a wait object becomes ready, it is added to the set of ready objects and the main loop takes an element from this set and asks it for one of the threads waiting on the object. It is the set I'm talking about ;) Sometimes the readiness of one of those objects can be changed from another thread (for now I'm using a helper thread for timers, and perhaps also for other things in the future - IO, wxWidgets integration, etc.). The main loop is in the Switcher.run() method towards the end of the following file: http://svn.berlios.de/viewcvs/tasklets/trunk/softlets/core.py?view=markup As you see, I actually do a "for" on the set, but I always break of the "for" loop after the first iteration... Which is not very elegant and understandable for the reader. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-29 19:10 Message: Logged In: YES user_id=80475 We've looked at a choose() method a couple of times and rejected it. Since the method gets an arbitrary element, it might as well get the first one it sees. But that is of little use in a loop (when do you ever need to get the same object over and over again?). Also, a choose method() would need to raise a KeyError if the set if emtpy and/or provide a default argument like dict.get() does. This complicates the heck out of using it. Put the two together and the idea loses any charm. Also, for mutable sets, a better approach is to pop() elements from the set and add them back when you're done with them. I'm not too concerned about atomicity. For one, that is almost never a good guide to API design. Second, it is implementation dependent (i.e. no guarantees for PyPy or Jython). Three, it generally indicates a problem in your design (if the set could mutate smaller during a thread accessing the set, then you have a race condition where the set could shrink to zero or not). Four, the right way to deal with atomicity issues is to use locks or control access via Queue. I do understand that basic motivation (I have a set, now how do I a representative element) but find the proposal lacking. It just doesn't do much for us. BTW, please post your use case (in a condensed form that gets to the essentials of why you think this method is needed).. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470 From noreply at sourceforge.net Tue Aug 30 09:03:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Aug 2005 00:03:33 -0700 Subject: [ python-Feature Requests-1275677 ] add a get() method to sets Message-ID: Feature Requests item #1275677, was opened at 2005-08-29 14:49 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&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: None Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Raymond Hettinger (rhettinger) Summary: add a get() method to sets Initial Comment: Hi, I would like to propose a new method for the builtin set objects. Currently we have a pop() method which pops an element from the set. What I often need, though, is a method that gets an arbitrary element without removing it (because adding / removing stuff is dealt with in another part of the program). Right now the simplest way to do that is : value = iter(my_set).next() There are two problems with this: 1. it's ugly and not very intuitive 2. it is not atomic; this means if another thread updates the set, I can get a "RuntimeError: dictionary changed size during iteration" (btw, the message is slightly wrong, it should be "set" instead of "dictionary") Although the first problem is rather minor (but annoying nevertheless), the second one is a real showstopper in some cases - yes, I did encounter it for real. There is a way to avoid the second problem : value = list(my_set)[0] But of course, not only it is still ugly, but it is also highly inefficient when the set is big. So in the end I am forced to use an explicit lock around the aforementioned construct (value = iter(my_set).next()) as well as around any other piece of code that can update the set from another thread. This is tedious and error-prone, and probably a bit inefficient. So for the bottom line: it would be in some cases very useful to have an atomic get() method in addition to the pop() method on sets. (it could probably be applied to frozensets and dicts too) The implementation would probably not be very difficult, since it's the same as pop() with the removal feature removed. ;) But I'm not familiar with the Python internals. What do you think ? Regards Antoine. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-08-30 08:03 Message: Logged In: YES user_id=6656 Mmm, the "v, = s" approach hadn't occurred to me and it seems ok. The others are all rather horribly indirect... (and, obviously, it's not about "need"). ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-30 00:09 Message: Logged In: YES user_id=133955 Hi again, > Antoine, yes a pop()/add() combination is efficient. Ok, thanks. > IMO, > it also clear in intent, easy to write, flexible enough for > a variety of applications, the pop() is atomic, Small correction: the pop() is atomic, but the pop/add sequence is not, AFAIU ;) > Question for Antoine: Have you ever had this need with > other containers? I think I had it for a dict sometime. For lists and tuples, you can just use my_container[0] of course. But sets are often used differently than dicts IMHO. Dicts are mappings: you give a precise key and get the exact value associated with it. Sets are bags: sometimes you just want to pick an item, as you would do in a real bag, without looking inside to choose a specific item. > Since choose() would not be a > mutating method, it would also apply to frozensets. Does it > have any use there? Any appearance in a loop would be farce > since it would always return the same value (the frozenset > never mutates). The variable to which you apply the method call could reference another frozenset on the next loop iteration... Yes, it doesn't sound very frequent. > Question for everyone: Is there any known application for > choose() that isn't met by pop()/add() irrespective of > whether it "feels right"? I don't think so indeed. (it would be the case if the API guaranteed atomicity in the case of single bultin method calls like choose()) > For applications other than Michael's, we won't know the > size of the set in advance. Are there any examples of using > choose() that won't have to have ugly EAFP or LBYL code to > handle the case where the set is empty? First, sometimes you know the set is non-empty without knowing its size in advance (for example you are inside a big block beginning with "if len(my_set)"). Second, error catching is still needed with other alternatives (you either have to catch KeyError when doing s.pop(), or StopIteration when doing iter(s).next()). > Rather than a method just for sets, is it a more appropriate > solution to have a generic function that takes any iterable > and returns its first element: Well, I thought global builtin functions were less favoured than methods. But this doesn't sound stupid. On the other hand, generic functions are less easy to find about (usually if I want to have the set API, I type help(set) in a Python shell which I always have open. But there is no quick way to have a list of the builtin functions that can apply to iterables (*)). In my experience, I often forget about the generic builtin functions that come with Python - maybe that's just me. (*) if there was a base type "iterable" with the generic method first() defined on it, as well as some of the other functions defined in the itertools module, it would probably be more elegant and more frequently used. Anyway, if the concern with builtin types is to avoid bloating the API, then I admit that it's a fair concern and that the motivation to add the choose() method might indeed not be convincing enough. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-29 23:30 Message: Logged In: YES user_id=80475 Exploratory questions: Michael, if you know there is only one element in a set, do you really need a custom method just to extract it? There are so many other ways. Given s=set([7]): 1) x = list(s)[0] 2) x = s.pop() 3) x, = s 4) x = max(s) yada yada yada Antoine, yes a pop()/add() combination is efficient. IMO, it also clear in intent, easy to write, flexible enough for a variety of applications, the pop() is atomic, and the approach also works with other mutable containers (dicts, lists, deques). Question for Antoine: Have you ever had this need with other containers? For instance, how do you find an arbitrary key in a dictionary without popping, iterating, or listing it? Question for everyone: Since choose() would not be a mutating method, it would also apply to frozensets. Does it have any use there? Any appearance in a loop would be farce since it would always return the same value (the frozenset never mutates). Question for everyone: Is there any known application for choose() that isn't met by pop()/add() irrespective of whether it "feels right"? For applications other than Michael's, we won't know the size of the set in advance. Are there any examples of using choose() that won't have to have ugly EAFP or LBYL code to handle the case where the set is empty? Rather than a method just for sets, is it a more appropriate solution to have a generic function that takes any iterable and returns its first element: def getfirst(it): for elem in it: return elem raise ValueError('iterator is empty') A function like this would work with almost anything: first(dict(a=1, b=2)) first(set([1, 2])) first([1,2]) first(open('myfile.txt')) . . . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-08-29 21:42 Message: Logged In: YES user_id=6656 _My_ use case for something like this is applying a series of constraints as set intersections until the set has one element; then I want to know what that element *is*. I could probably use .pop(), but it feels wrong, and I know I can (and indeed do) do iter(theSet).next() but that's obscure. ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 20:16 Message: Logged In: YES user_id=133955 > When choosing a ready object, you pop it to unready > because you're using it -- put it back in if the current use > won't cause blocking, or when that use finishes. That's not exactly my semantics (objects remain ready until they explicitly tell the contrary: for example a queue remains ready until it becomes empty), but I can live with a pop() / add() sequence provided it is efficient. Is it ? Otherwise I may go for "elem = iter(my_set).next()". Thanks for the very prompt answers, btw :) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-08-29 20:07 Message: Logged In: YES user_id=764593 This does look like pop might be a better choice. When choosing a ready object, you pop it to unready because you're using it -- put it back in if the current use won't cause blocking, or when that use finishes. When choosing a waiting ready thread, either the thread is no longer ready (so put it back in waiting, but you don't want it in ready), or it runs (so it should no longer be in waiting). ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 19:31 Message: Logged In: YES user_id=133955 Hi, Thanks for the detailed reply. So, atomicity cannot be guaranteed. I understand that (you might tell it to the Twisted folks by the way, because as far as I've seen some of their code relies on list operations being atomic in CPython ;-)). Remains the simplicity argument. As for the first objection: my set is mutated in the loop in ways that I cannot predict (because each element in the set points me in turn to a user-defined callback that will often alter the set ;-)). That explains why it *is* useful to get the "first" element repeatedly: the "first" element changes very often. As for the use case : I'm writing a small cooperative multithread package using generators (mostly for fun, but I'll be glad if it pleases others too): https://developer.berlios.de/projects/tasklets/ Scheduling is based on "wait objects": when a wait object becomes ready, it is added to the set of ready objects and the main loop takes an element from this set and asks it for one of the threads waiting on the object. It is the set I'm talking about ;) Sometimes the readiness of one of those objects can be changed from another thread (for now I'm using a helper thread for timers, and perhaps also for other things in the future - IO, wxWidgets integration, etc.). The main loop is in the Switcher.run() method towards the end of the following file: http://svn.berlios.de/viewcvs/tasklets/trunk/softlets/core.py?view=markup As you see, I actually do a "for" on the set, but I always break of the "for" loop after the first iteration... Which is not very elegant and understandable for the reader. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-29 18:10 Message: Logged In: YES user_id=80475 We've looked at a choose() method a couple of times and rejected it. Since the method gets an arbitrary element, it might as well get the first one it sees. But that is of little use in a loop (when do you ever need to get the same object over and over again?). Also, a choose method() would need to raise a KeyError if the set if emtpy and/or provide a default argument like dict.get() does. This complicates the heck out of using it. Put the two together and the idea loses any charm. Also, for mutable sets, a better approach is to pop() elements from the set and add them back when you're done with them. I'm not too concerned about atomicity. For one, that is almost never a good guide to API design. Second, it is implementation dependent (i.e. no guarantees for PyPy or Jython). Three, it generally indicates a problem in your design (if the set could mutate smaller during a thread accessing the set, then you have a race condition where the set could shrink to zero or not). Four, the right way to deal with atomicity issues is to use locks or control access via Queue. I do understand that basic motivation (I have a set, now how do I a representative element) but find the proposal lacking. It just doesn't do much for us. BTW, please post your use case (in a condensed form that gets to the essentials of why you think this method is needed).. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470 From noreply at sourceforge.net Tue Aug 30 09:06:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Aug 2005 00:06:34 -0700 Subject: [ python-Bugs-1010952 ] running test_codecmaps_* takes too much effort Message-ID: Bugs item #1010952, was opened at 2004-08-18 04:13 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010952&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: Ronald Oussoren (ronaldoussoren) Assigned to: Hye-Shik Chang (perky) Summary: running test_codecmaps_* takes too much effort Initial Comment: The only way I've found to actually run the codecmap tests is by running it over and over again, downloading the missing files when a test complains in between, until the tests no longer complains. E.g $ make test - test_codecmap_jp complains about a missing file - download this file $ make test - test_codecmap_jp complains about another missing filie - ... Another problem: it is completely unclear where I should place the downloaded files. I've worked around this by placing the files in Lib/test and patching test_multibytecodec_support to look for the files in os.path.dirname(__file__): cvs diff: Diffing . Index: test_multibytecodec_support.py ========================================= ========================== RCS file: /cvsroot/python/python/dist/src/Lib/test/ test_multibytecodec_support.py,v retrieving revision 1.5 diff -r1.5 test_multibytecodec_support.py 165a166 > self.mapfilename = os.path.join(os.path.dirname(__file__), self.mapfilename) It would be nice if there were a document that described what should be done to run these tests, adding the required files to CVS would be fine too :-) ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-08-30 16:06 Message: Logged In: YES user_id=55188 I wrote a patch that draws on lemburg's suggestion. Please test it: SF #1276356. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-10-14 05:04 Message: Logged In: YES user_id=38388 Just a suggestion: Why don't we add a new resource option to the test scripts and then have the tests download the files from the Internet as necessary ?! ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-14 04:59 Message: Logged In: YES user_id=469548 How about adding the files to nondist? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-10-14 00:12 Message: Logged In: YES user_id=29957 Could we at least get a single tarball/zip file of all of the files? At the moment, it takes a serious amount of effort to fetch all the files. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-20 16:26 Message: Logged In: YES user_id=21627 Adding the files to the CVS is unacceptable, because they would then end up in the distribution, and their size is considered unacceptable for distribution (let alone copyright issues with these files). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-18 04:19 Message: Logged In: YES user_id=580910 test_normalization suffers from a simular problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010952&group_id=5470 From noreply at sourceforge.net Tue Aug 30 11:16:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Aug 2005 02:16:28 -0700 Subject: [ python-Bugs-1276437 ] error converting locale number to decimal Message-ID: Bugs item #1276437, was opened at 2005-08-30 11:16 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=1276437&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: oswaldo (oswaldohm) Assigned to: Nobody/Anonymous (nobody) Summary: error converting locale number to decimal Initial Comment: Hello, When I try con convert a locale formated number to decimal y generate an error: >>> import locale >>> import decimal >>> locale.setlocale(locale.LC_ALL, "sp") 'Spanish_Spain.1252' >>> n = locale.format("%f", 123456.78, 1) >>> n '123.456,780000' >>> d = decimal.Decimal(n) File "", line 1, in ? File "C:\Python24\Lib\decimal.py", line 571, in __new__ self._sign, self._int, self._exp = context._raise_error(ConversionSyntax) File "C:\Python24\Lib\decimal.py", line 2266, in _raise_error raise error, explanation ''' decimal.InvalidOperation : ''' >>> Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276437&group_id=5470 From noreply at sourceforge.net Tue Aug 30 11:17:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Aug 2005 02:17:39 -0700 Subject: [ python-Bugs-1276437 ] error converting locale number to decimal Message-ID: Bugs item #1276437, was opened at 2005-08-30 11:16 Message generated for change (Settings changed) made by oswaldohm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276437&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: oswaldo (oswaldohm) >Assigned to: Facundo Batista (facundobatista) Summary: error converting locale number to decimal Initial Comment: Hello, When I try con convert a locale formated number to decimal y generate an error: >>> import locale >>> import decimal >>> locale.setlocale(locale.LC_ALL, "sp") 'Spanish_Spain.1252' >>> n = locale.format("%f", 123456.78, 1) >>> n '123.456,780000' >>> d = decimal.Decimal(n) File "", line 1, in ? File "C:\Python24\Lib\decimal.py", line 571, in __new__ self._sign, self._int, self._exp = context._raise_error(ConversionSyntax) File "C:\Python24\Lib\decimal.py", line 2266, in _raise_error raise error, explanation ''' decimal.InvalidOperation : ''' >>> Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276437&group_id=5470 From noreply at sourceforge.net Tue Aug 30 12:47:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Aug 2005 03:47:20 -0700 Subject: [ python-Bugs-1251300 ] Decoding with unicode_internal segfaults on UCS-4 builds Message-ID: Bugs item #1251300, was opened at 2005-08-03 21:49 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&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: Unicode Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nik Haldimann (nhaldimann) Assigned to: Walter D?rwald (doerwalter) Summary: Decoding with unicode_internal segfaults on UCS-4 builds Initial Comment: On UCS-4 builds, decoding a byte string with the unicode_internal codec doesn't correctly work for code points from 0x80000000 upwards and even segfaults. I have observed the same behaviour on 2.5 from CVS and 2.4.0 on OS X/PowerPC as well as on 2.3.5 on Linux/x86. Here's an example: Python 2.5a0 (#1, Aug 3 2005, 21:34:05) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> "\x7f\xff\xff\xff".decode("unicode_internal") u'\U7fffffff' >>> "\x80\x00\x00\x00".decode("unicode_internal") u'\x00' >>> "\x80\x00\x00\x01".decode("unicode_internal") u'\x01' >>> "\x81\x00\x00\x00".decode("unicode_internal") Segmentation fault On little endian architectures the byte strings must be reversed for the same effect. I'm not sure if I understand what's going on, but I guess there are 2 solution strategies: 1. Make unicode_internal work for any code point up to 0xFFFFFFFF. 2. Make unicode_internal raise a UnicodeDecodeError for anything above 0x10FFFF (== sys.maxunicode for UCS-4 builds). It seems like there are no unicode code points above 0x10FFFF, so the latter solution feels more correct to me, even though it might break backwards compatibility a tiny bit. The unicodeescape codec already does a similar thing: >>> u"\U00110000" UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-08-30 12:47 Message: Logged In: YES user_id=89016 I've checked in a version that detects truncated data as: Include/unicodeobject.h 2.49 Lib/test/test_codeccallbacks.py 1.18 Lib/test/test_codecs.py 1.26 Misc/NEWS 1.1358 Modules/_codecsmodule.c 2.22 Objects/unicodeobject.c 2.231 and Include/unicodeobject.h 2.48.2.1 Lib/test/test_codeccallbacks.py 1.16.4.2 Lib/test/test_codecs.py 1.15.2.8 Misc/NEWS 1.1193.2.92 Modules/_codecsmodule.c 2.20.2.2 Objects/unicodeobject.c 2.230.2.1 Thanks for the patch! ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-19 17:45 Message: Logged In: YES user_id=38388 Assigning to Walter, the error handler expert :-) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-19 17:39 Message: Logged In: YES user_id=89016 The data the handler sees is nonsensical by definition. ;) To get an idea how to handle an incorrect length, take a look at Objects/unicodeobject.c::PyUnicode_DecodeUTF16Stateful() ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-19 16:17 Message: Logged In: YES user_id=1317086 I agree about the ifdefs. I'm not sure about how to handle input strings of incorrect length. I guess raising an UnicodeDecodeError is in order. But I think it doesn't make sense to let it pass through the error handler, since the data the handler would see is potentially nonsensical (e.g., the code point value). Can you comment on this? Is it ok to raise a UnicodeDecodeError and skip the error handler here? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-18 22:17 Message: Logged In: YES user_id=89016 The patch has a problem with input strings of a length that is not a multiple of 4, e.g. "\x00".decode("unicode-internal") returns u"" instead of raising an error. Also in a UCS-2 build most of the tests are irrelevant (as it's not possible to create codepoints above 0x10ffff even when using surrogates), so probably they should be ifdef'd out. ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 23:08 Message: Logged In: YES user_id=1317086 Here's the patch with error handler support + test. Again: Please review carefully. ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 18:35 Message: Logged In: YES user_id=1317086 Ah, that PEP clears some things up for me. I will look into it, but I hope you realize this requires tinkering with unicodeobject.c since the error handler code seems to live there. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-05 18:03 Message: Logged In: YES user_id=89016 Your patch doesn't support PEP 293 error handlers. Could you add support for that? ---------------------------------------------------------------------- Comment By: Nik Haldimann (nhaldimann) Date: 2005-08-05 16:50 Message: Logged In: YES user_id=1317086 OK, I put something together. Please review carefully as I'm not very familiar with the C API. I have tested this with the CVS HEAD on OS X and Linux. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-04 16:41 Message: Logged In: YES user_id=38388 I think solution 2 is the right approach, since UCS-4 only has 0x10FFFF possible code points. Could you provide a patch ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1251300&group_id=5470 From noreply at sourceforge.net Tue Aug 30 12:48:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Aug 2005 03:48:51 -0700 Subject: [ python-Bugs-1276509 ] 2.4.1 make fails on Solaris 10 Message-ID: Bugs item #1276509, was opened at 2005-08-30 12:48 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=1276509&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: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: csmuc (chrschaffer) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 make fails on Solaris 10 Initial Comment: Hi all, my efforts building Python 2.4.1 on Solaris 10(x386) failed. The error mesage reads: (...)Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus *** Error code 1 make: Fatal error: Command failed for target `Objects/complexobject.o' I found bug 970334 dealing with that topic, but I didn't find a solution provided. I tried with various compilers and libraries, e.g. /opt/sfw/bin/gcc --version gcc (GCC) 3.4.2 Copyright (C) 2004 Free Software Foundation, Inc. /opt/csw/gcc3/bin/gcc --version gcc (GCC) 3.4.4 Copyright (C) 2004 Free Software Foundation, Inc. /usr/local/bin/gcc --version gcc (GCC) 3.3.2 The same result with any of them. I didn't get the solution provided in http://mail.python.org/pipermail/python-list/2005-August/293795.html to work for me, unfortunately. I'd be glad, if you could have a look into this issue. Thanks in advance, Chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&group_id=5470 From noreply at sourceforge.net Tue Aug 30 12:48:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Aug 2005 03:48:58 -0700 Subject: [ python-Bugs-1276437 ] error converting locale number to decimal Message-ID: Bugs item #1276437, was opened at 2005-08-30 18:16 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276437&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: oswaldo (oswaldohm) Assigned to: Facundo Batista (facundobatista) Summary: error converting locale number to decimal Initial Comment: Hello, When I try con convert a locale formated number to decimal y generate an error: >>> import locale >>> import decimal >>> locale.setlocale(locale.LC_ALL, "sp") 'Spanish_Spain.1252' >>> n = locale.format("%f", 123456.78, 1) >>> n '123.456,780000' >>> d = decimal.Decimal(n) File "", line 1, in ? File "C:\Python24\Lib\decimal.py", line 571, in __new__ self._sign, self._int, self._exp = context._raise_error(ConversionSyntax) File "C:\Python24\Lib\decimal.py", line 2266, in _raise_error raise error, explanation ''' decimal.InvalidOperation : ''' >>> Thanks ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-08-30 19:48 Message: Logged In: YES user_id=671362 I guess this is because '123.456,780000' does not conform to the decimal numeric string syntax : decimal-part ::= digits '.' [digits] | ['.'] digits see : http://docs.python.org/lib/node177.html It does not seem to be a bug to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276437&group_id=5470 From noreply at sourceforge.net Tue Aug 30 13:47:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Aug 2005 04:47:08 -0700 Subject: [ python-Feature Requests-1275677 ] add a get() method to sets Message-ID: Feature Requests item #1275677, was opened at 2005-08-29 08:49 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&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: None Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Raymond Hettinger (rhettinger) Summary: add a get() method to sets Initial Comment: Hi, I would like to propose a new method for the builtin set objects. Currently we have a pop() method which pops an element from the set. What I often need, though, is a method that gets an arbitrary element without removing it (because adding / removing stuff is dealt with in another part of the program). Right now the simplest way to do that is : value = iter(my_set).next() There are two problems with this: 1. it's ugly and not very intuitive 2. it is not atomic; this means if another thread updates the set, I can get a "RuntimeError: dictionary changed size during iteration" (btw, the message is slightly wrong, it should be "set" instead of "dictionary") Although the first problem is rather minor (but annoying nevertheless), the second one is a real showstopper in some cases - yes, I did encounter it for real. There is a way to avoid the second problem : value = list(my_set)[0] But of course, not only it is still ugly, but it is also highly inefficient when the set is big. So in the end I am forced to use an explicit lock around the aforementioned construct (value = iter(my_set).next()) as well as around any other piece of code that can update the set from another thread. This is tedious and error-prone, and probably a bit inefficient. So for the bottom line: it would be in some cases very useful to have an atomic get() method in addition to the pop() method on sets. (it could probably be applied to frozensets and dicts too) The implementation would probably not be very difficult, since it's the same as pop() with the removal feature removed. ;) But I'm not familiar with the Python internals. What do you think ? Regards Antoine. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-30 06:47 Message: Logged In: YES user_id=80475 > > Question for everyone: Is there any known application for > > choose() that isn't met by pop()/add() irrespective of > > whether it "feels right"? [Antoine] > I don't think so indeed. [mwh] > Mmm, the "v, = s" approach hadn't occurred to me and it > seems ok. Those two answers suggest this RFE is unnecessary. If you guys agree, please close. If not, I'll ponder it further. Right now, I'm disinclined to introduce a method that I think is awkward to use. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-08-30 02:03 Message: Logged In: YES user_id=6656 Mmm, the "v, = s" approach hadn't occurred to me and it seems ok. The others are all rather horribly indirect... (and, obviously, it's not about "need"). ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 18:09 Message: Logged In: YES user_id=133955 Hi again, > Antoine, yes a pop()/add() combination is efficient. Ok, thanks. > IMO, > it also clear in intent, easy to write, flexible enough for > a variety of applications, the pop() is atomic, Small correction: the pop() is atomic, but the pop/add sequence is not, AFAIU ;) > Question for Antoine: Have you ever had this need with > other containers? I think I had it for a dict sometime. For lists and tuples, you can just use my_container[0] of course. But sets are often used differently than dicts IMHO. Dicts are mappings: you give a precise key and get the exact value associated with it. Sets are bags: sometimes you just want to pick an item, as you would do in a real bag, without looking inside to choose a specific item. > Since choose() would not be a > mutating method, it would also apply to frozensets. Does it > have any use there? Any appearance in a loop would be farce > since it would always return the same value (the frozenset > never mutates). The variable to which you apply the method call could reference another frozenset on the next loop iteration... Yes, it doesn't sound very frequent. > Question for everyone: Is there any known application for > choose() that isn't met by pop()/add() irrespective of > whether it "feels right"? I don't think so indeed. (it would be the case if the API guaranteed atomicity in the case of single bultin method calls like choose()) > For applications other than Michael's, we won't know the > size of the set in advance. Are there any examples of using > choose() that won't have to have ugly EAFP or LBYL code to > handle the case where the set is empty? First, sometimes you know the set is non-empty without knowing its size in advance (for example you are inside a big block beginning with "if len(my_set)"). Second, error catching is still needed with other alternatives (you either have to catch KeyError when doing s.pop(), or StopIteration when doing iter(s).next()). > Rather than a method just for sets, is it a more appropriate > solution to have a generic function that takes any iterable > and returns its first element: Well, I thought global builtin functions were less favoured than methods. But this doesn't sound stupid. On the other hand, generic functions are less easy to find about (usually if I want to have the set API, I type help(set) in a Python shell which I always have open. But there is no quick way to have a list of the builtin functions that can apply to iterables (*)). In my experience, I often forget about the generic builtin functions that come with Python - maybe that's just me. (*) if there was a base type "iterable" with the generic method first() defined on it, as well as some of the other functions defined in the itertools module, it would probably be more elegant and more frequently used. Anyway, if the concern with builtin types is to avoid bloating the API, then I admit that it's a fair concern and that the motivation to add the choose() method might indeed not be convincing enough. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-29 17:30 Message: Logged In: YES user_id=80475 Exploratory questions: Michael, if you know there is only one element in a set, do you really need a custom method just to extract it? There are so many other ways. Given s=set([7]): 1) x = list(s)[0] 2) x = s.pop() 3) x, = s 4) x = max(s) yada yada yada Antoine, yes a pop()/add() combination is efficient. IMO, it also clear in intent, easy to write, flexible enough for a variety of applications, the pop() is atomic, and the approach also works with other mutable containers (dicts, lists, deques). Question for Antoine: Have you ever had this need with other containers? For instance, how do you find an arbitrary key in a dictionary without popping, iterating, or listing it? Question for everyone: Since choose() would not be a mutating method, it would also apply to frozensets. Does it have any use there? Any appearance in a loop would be farce since it would always return the same value (the frozenset never mutates). Question for everyone: Is there any known application for choose() that isn't met by pop()/add() irrespective of whether it "feels right"? For applications other than Michael's, we won't know the size of the set in advance. Are there any examples of using choose() that won't have to have ugly EAFP or LBYL code to handle the case where the set is empty? Rather than a method just for sets, is it a more appropriate solution to have a generic function that takes any iterable and returns its first element: def getfirst(it): for elem in it: return elem raise ValueError('iterator is empty') A function like this would work with almost anything: first(dict(a=1, b=2)) first(set([1, 2])) first([1,2]) first(open('myfile.txt')) . . . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-08-29 15:42 Message: Logged In: YES user_id=6656 _My_ use case for something like this is applying a series of constraints as set intersections until the set has one element; then I want to know what that element *is*. I could probably use .pop(), but it feels wrong, and I know I can (and indeed do) do iter(theSet).next() but that's obscure. ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 14:16 Message: Logged In: YES user_id=133955 > When choosing a ready object, you pop it to unready > because you're using it -- put it back in if the current use > won't cause blocking, or when that use finishes. That's not exactly my semantics (objects remain ready until they explicitly tell the contrary: for example a queue remains ready until it becomes empty), but I can live with a pop() / add() sequence provided it is efficient. Is it ? Otherwise I may go for "elem = iter(my_set).next()". Thanks for the very prompt answers, btw :) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-08-29 14:07 Message: Logged In: YES user_id=764593 This does look like pop might be a better choice. When choosing a ready object, you pop it to unready because you're using it -- put it back in if the current use won't cause blocking, or when that use finishes. When choosing a waiting ready thread, either the thread is no longer ready (so put it back in waiting, but you don't want it in ready), or it runs (so it should no longer be in waiting). ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 13:31 Message: Logged In: YES user_id=133955 Hi, Thanks for the detailed reply. So, atomicity cannot be guaranteed. I understand that (you might tell it to the Twisted folks by the way, because as far as I've seen some of their code relies on list operations being atomic in CPython ;-)). Remains the simplicity argument. As for the first objection: my set is mutated in the loop in ways that I cannot predict (because each element in the set points me in turn to a user-defined callback that will often alter the set ;-)). That explains why it *is* useful to get the "first" element repeatedly: the "first" element changes very often. As for the use case : I'm writing a small cooperative multithread package using generators (mostly for fun, but I'll be glad if it pleases others too): https://developer.berlios.de/projects/tasklets/ Scheduling is based on "wait objects": when a wait object becomes ready, it is added to the set of ready objects and the main loop takes an element from this set and asks it for one of the threads waiting on the object. It is the set I'm talking about ;) Sometimes the readiness of one of those objects can be changed from another thread (for now I'm using a helper thread for timers, and perhaps also for other things in the future - IO, wxWidgets integration, etc.). The main loop is in the Switcher.run() method towards the end of the following file: http://svn.berlios.de/viewcvs/tasklets/trunk/softlets/core.py?view=markup As you see, I actually do a "for" on the set, but I always break of the "for" loop after the first iteration... Which is not very elegant and understandable for the reader. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-29 12:10 Message: Logged In: YES user_id=80475 We've looked at a choose() method a couple of times and rejected it. Since the method gets an arbitrary element, it might as well get the first one it sees. But that is of little use in a loop (when do you ever need to get the same object over and over again?). Also, a choose method() would need to raise a KeyError if the set if emtpy and/or provide a default argument like dict.get() does. This complicates the heck out of using it. Put the two together and the idea loses any charm. Also, for mutable sets, a better approach is to pop() elements from the set and add them back when you're done with them. I'm not too concerned about atomicity. For one, that is almost never a good guide to API design. Second, it is implementation dependent (i.e. no guarantees for PyPy or Jython). Three, it generally indicates a problem in your design (if the set could mutate smaller during a thread accessing the set, then you have a race condition where the set could shrink to zero or not). Four, the right way to deal with atomicity issues is to use locks or control access via Queue. I do understand that basic motivation (I have a set, now how do I a representative element) but find the proposal lacking. It just doesn't do much for us. BTW, please post your use case (in a condensed form that gets to the essentials of why you think this method is needed).. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470 From noreply at sourceforge.net Tue Aug 30 14:53:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Aug 2005 05:53:00 -0700 Subject: [ python-Bugs-1276587 ] dict('') doesn't raise a value error Message-ID: Bugs item #1276587, was opened at 2005-08-30 12:52 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=1276587&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: Mike Foord (mjfoord) Assigned to: Nobody/Anonymous (nobody) Summary: dict('') doesn't raise a value error Initial Comment: The dict function will theoretically accept any sequence or bounded iterable that yields (key, value) tuples. A side effect is that dict('') is valid - producing an emtpy dictionary. dict(x) where x is *any* string other than '' fails with a ValueError. I suggest that dict('') ought to produce a ValueError to as a string is *never* a valid input to the dict function. The current situation allows obscure errors to pass unnoticed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276587&group_id=5470 From noreply at sourceforge.net Tue Aug 30 14:58:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Aug 2005 05:58:37 -0700 Subject: [ python-Bugs-1258485 ] http auth documentation/implementation conflict Message-ID: Bugs item #1258485, was opened at 2005-08-13 16:49 Message generated for change (Comment added) made by mjfoord You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258485&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: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: http auth documentation/implementation conflict Initial Comment: [forwarded from http://bugs.debian.org/304925] Bug reporter writes: I was trying to implement a basic HTTP client using HTTP basic authorization. The current preferred method of doing this is by using urllib2 HTTPPasswordMgr. A simple test snippet to try this: pwmgr=urllib2.HTTPPasswordMgrWithDefaultRealm() pwmgr.add_password(None, url, username, password) handler=urllib2.HTTPBasicAuthHandler(pwmgr) opener=urllib2.build_opener(handler) urllib2.install_opener(opener) u=urllib2.urlopen(url) This did not work. Modifying the second line to: pwmgr.add_password(None, urlparse.urlparse(url)[1], username, password) fixed things, which shows a problem in the documentation: instead of a URI or sequence of URIs the add_password method takes a hostname. The documented behaviour would be better since it allows for multiple passwords per host, although in reality those will use different realms. So I suggest not changing the code in order to not break existing application but fixing the documentation instead. ---------------------------------------------------------------------- Comment By: Mike Foord (mjfoord) Date: 2005-08-30 12:58 Message: Logged In: YES user_id=1123892 I think it likely that the OP was using a URL that *included* the protocol - (i.e. "http://www.somedomain.com/path") instead of just "www.somedomain.com/path". It is a problem that also bit me - and could *definitely* do with a mention in the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258485&group_id=5470 From noreply at sourceforge.net Tue Aug 30 16:39:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Aug 2005 07:39:33 -0700 Subject: [ python-Bugs-1276587 ] dict('') doesn't raise a value error Message-ID: Bugs item #1276587, was opened at 2005-08-30 08:52 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276587&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: Mike Foord (mjfoord) Assigned to: Nobody/Anonymous (nobody) Summary: dict('') doesn't raise a value error Initial Comment: The dict function will theoretically accept any sequence or bounded iterable that yields (key, value) tuples. A side effect is that dict('') is valid - producing an emtpy dictionary. dict(x) where x is *any* string other than '' fails with a ValueError. I suggest that dict('') ought to produce a ValueError to as a string is *never* a valid input to the dict function. The current situation allows obscure errors to pass unnoticed. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-08-30 10:39 Message: Logged In: YES user_id=31435 It's not theoretical: it's a fact that dict() accepts any iterable producing iterables each producing 2 objects (the latter don't have to be tuples; a (key, value) tuple is just one kind of iterable producing 2 objects; e.g., dict(["ab"]) == {'a': 'b'}). An empty str meets the input requirements, so there's no way to stop this without special-case type-sniffing. That's very unattractive, in part because it's impossible to guess which kinds of empty iterables would necessarily lead to an exception when passed to dict() had they not been empty. For example, passing an empty array.array (of any flavor) to dict() also constructs an empty dict. The universe of iterable objects is vast. Keeping it uniform and easy to explain (an empty iterable produces an empty dict) seems better to me than adding a maze of special cases that's bound to change over time ("except for an empty str" ... "oh, or an empty unicode" ... "oh, or an empty array.array" ... "oh, or an empty file" ... "oh, oops, guess not, cuz a file with two lines works fine" ... etc). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276587&group_id=5470 From noreply at sourceforge.net Tue Aug 30 17:59:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Aug 2005 08:59:40 -0700 Subject: [ python-Bugs-1276768 ] dirutils.mkpath (verbose option does not work) Message-ID: Bugs item #1276768, was opened at 2005-08-30 15:59 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=1276768&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: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: gorilla_killa (gorilla_killa) Assigned to: Nobody/Anonymous (nobody) Summary: dirutils.mkpath (verbose option does not work) Initial Comment: The Verbose option does not work. Looked at the python script for dir_utils.py and the verbose parameter is not used in the code. Please fix this simple bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276768&group_id=5470 From noreply at sourceforge.net Tue Aug 30 21:23:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Aug 2005 12:23:08 -0700 Subject: [ python-Bugs-1276437 ] error converting locale number to decimal Message-ID: Bugs item #1276437, was opened at 2005-08-30 11:16 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276437&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: Closed >Resolution: Invalid Priority: 5 Submitted By: oswaldo (oswaldohm) Assigned to: Facundo Batista (facundobatista) Summary: error converting locale number to decimal Initial Comment: Hello, When I try con convert a locale formated number to decimal y generate an error: >>> import locale >>> import decimal >>> locale.setlocale(locale.LC_ALL, "sp") 'Spanish_Spain.1252' >>> n = locale.format("%f", 123456.78, 1) >>> n '123.456,780000' >>> d = decimal.Decimal(n) File "", line 1, in ? File "C:\Python24\Lib\decimal.py", line 571, in __new__ self._sign, self._int, self._exp = context._raise_error(ConversionSyntax) File "C:\Python24\Lib\decimal.py", line 2266, in _raise_error raise error, explanation ''' decimal.InvalidOperation : ''' >>> Thanks ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-30 21:23 Message: Logged In: YES user_id=1188172 Correct. Decimal cannot guess which locale your number string might be in, so please format the float using regular string formatting and not locale.format. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-08-30 12:48 Message: Logged In: YES user_id=671362 I guess this is because '123.456,780000' does not conform to the decimal numeric string syntax : decimal-part ::= digits '.' [digits] | ['.'] digits see : http://docs.python.org/lib/node177.html It does not seem to be a bug to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276437&group_id=5470 From noreply at sourceforge.net Tue Aug 30 22:06:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Aug 2005 13:06:51 -0700 Subject: [ python-Feature Requests-1275677 ] add a get() method to sets Message-ID: Feature Requests item #1275677, was opened at 2005-08-29 08:49 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&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: None Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Raymond Hettinger (rhettinger) Summary: add a get() method to sets Initial Comment: Hi, I would like to propose a new method for the builtin set objects. Currently we have a pop() method which pops an element from the set. What I often need, though, is a method that gets an arbitrary element without removing it (because adding / removing stuff is dealt with in another part of the program). Right now the simplest way to do that is : value = iter(my_set).next() There are two problems with this: 1. it's ugly and not very intuitive 2. it is not atomic; this means if another thread updates the set, I can get a "RuntimeError: dictionary changed size during iteration" (btw, the message is slightly wrong, it should be "set" instead of "dictionary") Although the first problem is rather minor (but annoying nevertheless), the second one is a real showstopper in some cases - yes, I did encounter it for real. There is a way to avoid the second problem : value = list(my_set)[0] But of course, not only it is still ugly, but it is also highly inefficient when the set is big. So in the end I am forced to use an explicit lock around the aforementioned construct (value = iter(my_set).next()) as well as around any other piece of code that can update the set from another thread. This is tedious and error-prone, and probably a bit inefficient. So for the bottom line: it would be in some cases very useful to have an atomic get() method in addition to the pop() method on sets. (it could probably be applied to frozensets and dicts too) The implementation would probably not be very difficult, since it's the same as pop() with the removal feature removed. ;) But I'm not familiar with the Python internals. What do you think ? Regards Antoine. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-30 15:06 Message: Logged In: YES user_id=80475 For the record, here are some research results. Java's set objects do not have a choose() method: http://java.sun.com/j2se/1.4.2/docs/api/java/util/Set.html In contrast, SETL does provide a function for extracting arbitrary elements. The empty set case is handled by returning Om which is a singleton object guaranteed not to be an element of any set. The Om value is especially useful in SETL because it can be passed upward through other functions (much in the same way that NANs can trickle through a calculation without killing it). Python has no equivalent of Om. http://www.cs.nyu.edu/~bacon/setl-doc.html#arb Core Perl only has arrays and hashes. Mathematica provides set operations on lists (union, intersection, complement). Rather than having a set specific function for extraction, list functions are used. The one providing choose-like functionality is First(). It is equivalent to indexing: a[0] http://documents.wolfram.com/mathematica/functions/First ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-30 06:47 Message: Logged In: YES user_id=80475 > > Question for everyone: Is there any known application for > > choose() that isn't met by pop()/add() irrespective of > > whether it "feels right"? [Antoine] > I don't think so indeed. [mwh] > Mmm, the "v, = s" approach hadn't occurred to me and it > seems ok. Those two answers suggest this RFE is unnecessary. If you guys agree, please close. If not, I'll ponder it further. Right now, I'm disinclined to introduce a method that I think is awkward to use. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-08-30 02:03 Message: Logged In: YES user_id=6656 Mmm, the "v, = s" approach hadn't occurred to me and it seems ok. The others are all rather horribly indirect... (and, obviously, it's not about "need"). ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 18:09 Message: Logged In: YES user_id=133955 Hi again, > Antoine, yes a pop()/add() combination is efficient. Ok, thanks. > IMO, > it also clear in intent, easy to write, flexible enough for > a variety of applications, the pop() is atomic, Small correction: the pop() is atomic, but the pop/add sequence is not, AFAIU ;) > Question for Antoine: Have you ever had this need with > other containers? I think I had it for a dict sometime. For lists and tuples, you can just use my_container[0] of course. But sets are often used differently than dicts IMHO. Dicts are mappings: you give a precise key and get the exact value associated with it. Sets are bags: sometimes you just want to pick an item, as you would do in a real bag, without looking inside to choose a specific item. > Since choose() would not be a > mutating method, it would also apply to frozensets. Does it > have any use there? Any appearance in a loop would be farce > since it would always return the same value (the frozenset > never mutates). The variable to which you apply the method call could reference another frozenset on the next loop iteration... Yes, it doesn't sound very frequent. > Question for everyone: Is there any known application for > choose() that isn't met by pop()/add() irrespective of > whether it "feels right"? I don't think so indeed. (it would be the case if the API guaranteed atomicity in the case of single bultin method calls like choose()) > For applications other than Michael's, we won't know the > size of the set in advance. Are there any examples of using > choose() that won't have to have ugly EAFP or LBYL code to > handle the case where the set is empty? First, sometimes you know the set is non-empty without knowing its size in advance (for example you are inside a big block beginning with "if len(my_set)"). Second, error catching is still needed with other alternatives (you either have to catch KeyError when doing s.pop(), or StopIteration when doing iter(s).next()). > Rather than a method just for sets, is it a more appropriate > solution to have a generic function that takes any iterable > and returns its first element: Well, I thought global builtin functions were less favoured than methods. But this doesn't sound stupid. On the other hand, generic functions are less easy to find about (usually if I want to have the set API, I type help(set) in a Python shell which I always have open. But there is no quick way to have a list of the builtin functions that can apply to iterables (*)). In my experience, I often forget about the generic builtin functions that come with Python - maybe that's just me. (*) if there was a base type "iterable" with the generic method first() defined on it, as well as some of the other functions defined in the itertools module, it would probably be more elegant and more frequently used. Anyway, if the concern with builtin types is to avoid bloating the API, then I admit that it's a fair concern and that the motivation to add the choose() method might indeed not be convincing enough. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-29 17:30 Message: Logged In: YES user_id=80475 Exploratory questions: Michael, if you know there is only one element in a set, do you really need a custom method just to extract it? There are so many other ways. Given s=set([7]): 1) x = list(s)[0] 2) x = s.pop() 3) x, = s 4) x = max(s) yada yada yada Antoine, yes a pop()/add() combination is efficient. IMO, it also clear in intent, easy to write, flexible enough for a variety of applications, the pop() is atomic, and the approach also works with other mutable containers (dicts, lists, deques). Question for Antoine: Have you ever had this need with other containers? For instance, how do you find an arbitrary key in a dictionary without popping, iterating, or listing it? Question for everyone: Since choose() would not be a mutating method, it would also apply to frozensets. Does it have any use there? Any appearance in a loop would be farce since it would always return the same value (the frozenset never mutates). Question for everyone: Is there any known application for choose() that isn't met by pop()/add() irrespective of whether it "feels right"? For applications other than Michael's, we won't know the size of the set in advance. Are there any examples of using choose() that won't have to have ugly EAFP or LBYL code to handle the case where the set is empty? Rather than a method just for sets, is it a more appropriate solution to have a generic function that takes any iterable and returns its first element: def getfirst(it): for elem in it: return elem raise ValueError('iterator is empty') A function like this would work with almost anything: first(dict(a=1, b=2)) first(set([1, 2])) first([1,2]) first(open('myfile.txt')) . . . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-08-29 15:42 Message: Logged In: YES user_id=6656 _My_ use case for something like this is applying a series of constraints as set intersections until the set has one element; then I want to know what that element *is*. I could probably use .pop(), but it feels wrong, and I know I can (and indeed do) do iter(theSet).next() but that's obscure. ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 14:16 Message: Logged In: YES user_id=133955 > When choosing a ready object, you pop it to unready > because you're using it -- put it back in if the current use > won't cause blocking, or when that use finishes. That's not exactly my semantics (objects remain ready until they explicitly tell the contrary: for example a queue remains ready until it becomes empty), but I can live with a pop() / add() sequence provided it is efficient. Is it ? Otherwise I may go for "elem = iter(my_set).next()". Thanks for the very prompt answers, btw :) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-08-29 14:07 Message: Logged In: YES user_id=764593 This does look like pop might be a better choice. When choosing a ready object, you pop it to unready because you're using it -- put it back in if the current use won't cause blocking, or when that use finishes. When choosing a waiting ready thread, either the thread is no longer ready (so put it back in waiting, but you don't want it in ready), or it runs (so it should no longer be in waiting). ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 13:31 Message: Logged In: YES user_id=133955 Hi, Thanks for the detailed reply. So, atomicity cannot be guaranteed. I understand that (you might tell it to the Twisted folks by the way, because as far as I've seen some of their code relies on list operations being atomic in CPython ;-)). Remains the simplicity argument. As for the first objection: my set is mutated in the loop in ways that I cannot predict (because each element in the set points me in turn to a user-defined callback that will often alter the set ;-)). That explains why it *is* useful to get the "first" element repeatedly: the "first" element changes very often. As for the use case : I'm writing a small cooperative multithread package using generators (mostly for fun, but I'll be glad if it pleases others too): https://developer.berlios.de/projects/tasklets/ Scheduling is based on "wait objects": when a wait object becomes ready, it is added to the set of ready objects and the main loop takes an element from this set and asks it for one of the threads waiting on the object. It is the set I'm talking about ;) Sometimes the readiness of one of those objects can be changed from another thread (for now I'm using a helper thread for timers, and perhaps also for other things in the future - IO, wxWidgets integration, etc.). The main loop is in the Switcher.run() method towards the end of the following file: http://svn.berlios.de/viewcvs/tasklets/trunk/softlets/core.py?view=markup As you see, I actually do a "for" on the set, but I always break of the "for" loop after the first iteration... Which is not very elegant and understandable for the reader. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-29 12:10 Message: Logged In: YES user_id=80475 We've looked at a choose() method a couple of times and rejected it. Since the method gets an arbitrary element, it might as well get the first one it sees. But that is of little use in a loop (when do you ever need to get the same object over and over again?). Also, a choose method() would need to raise a KeyError if the set if emtpy and/or provide a default argument like dict.get() does. This complicates the heck out of using it. Put the two together and the idea loses any charm. Also, for mutable sets, a better approach is to pop() elements from the set and add them back when you're done with them. I'm not too concerned about atomicity. For one, that is almost never a good guide to API design. Second, it is implementation dependent (i.e. no guarantees for PyPy or Jython). Three, it generally indicates a problem in your design (if the set could mutate smaller during a thread accessing the set, then you have a race condition where the set could shrink to zero or not). Four, the right way to deal with atomicity issues is to use locks or control access via Queue. I do understand that basic motivation (I have a set, now how do I a representative element) but find the proposal lacking. It just doesn't do much for us. BTW, please post your use case (in a condensed form that gets to the essentials of why you think this method is needed).. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470 From noreply at sourceforge.net Wed Aug 31 01:57:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Aug 2005 16:57:09 -0700 Subject: [ python-Bugs-1277016 ] Sentence fragment in urlparse documentation Message-ID: Bugs item #1277016, was opened at 2005-08-30 19:57 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=1277016&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Nobody/Anonymous (nobody) Summary: Sentence fragment in urlparse documentation Initial Comment: The urlparse documentation contains this sentence fragment: "This should generally be used instead of urlparse() if the more recent URL syntax allowing parameters to be applied to each segment of the path portion of the URL (see RFC 2396)."[1] >From the context, I infer that the sentence should read something like: "This should generally be used instead of urlparse() if you do not wish to support the more recent URL syntax allowing parameters to be applied to each segment of the path portion of the URL (see RFC 2396)." ----- [1] http://www.python.org/dev/doc/devel/lib/module-urlparse.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277016&group_id=5470 From noreply at sourceforge.net Wed Aug 31 07:52:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Aug 2005 22:52:53 -0700 Subject: [ python-Bugs-1277098 ] imaplib Imap.select() uses comparison to 'None' for boolean Message-ID: Bugs item #1277098, was opened at 2005-08-31 15:52 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=1277098&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Stephen Thorne (jerub) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib Imap.select() uses comparison to 'None' for boolean Initial Comment: The imap class's method for selecting a mailbox in read only mode is subtly broken. Calling i.select('INBOX', readonly=0) will cause the imap library to open the mailbox in EXAMINE mode, not SELECT. def select(self, mailbox='INBOX', readonly=None): if readonly is not None: name = 'EXAMINE' else: name = 'SELECT' So passing what seems to be a boolean option into the function causes unexpected circumstances in client code. Recommend that the comparison be changed to 'if readonly:'. I have verified this code exists in python2.3 and in python cvs head. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277098&group_id=5470 From noreply at sourceforge.net Wed Aug 31 07:54:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Aug 2005 22:54:01 -0700 Subject: [ python-Bugs-1277098 ] imaplib Imap.select() uses comparison to 'None' for boolean Message-ID: Bugs item #1277098, was opened at 2005-08-31 15:52 Message generated for change (Comment added) made by jerub You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277098&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Stephen Thorne (jerub) >Assigned to: Piers Lauder (pierslauder) Summary: imaplib Imap.select() uses comparison to 'None' for boolean Initial Comment: The imap class's method for selecting a mailbox in read only mode is subtly broken. Calling i.select('INBOX', readonly=0) will cause the imap library to open the mailbox in EXAMINE mode, not SELECT. def select(self, mailbox='INBOX', readonly=None): if readonly is not None: name = 'EXAMINE' else: name = 'SELECT' So passing what seems to be a boolean option into the function causes unexpected circumstances in client code. Recommend that the comparison be changed to 'if readonly:'. I have verified this code exists in python2.3 and in python cvs head. ---------------------------------------------------------------------- >Comment By: Stephen Thorne (jerub) Date: 2005-08-31 15:54 Message: Logged In: YES user_id=100823 assigned to pierslauder as per abaxter's request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277098&group_id=5470 From noreply at sourceforge.net Wed Aug 31 12:32:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 03:32:34 -0700 Subject: [ python-Bugs-1277098 ] imaplib Imap.select() uses comparison to 'None' for boolean Message-ID: Bugs item #1277098, was opened at 2005-08-31 15:52 Message generated for change (Comment added) made by pierslauder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277098&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Stephen Thorne (jerub) Assigned to: Piers Lauder (pierslauder) Summary: imaplib Imap.select() uses comparison to 'None' for boolean Initial Comment: The imap class's method for selecting a mailbox in read only mode is subtly broken. Calling i.select('INBOX', readonly=0) will cause the imap library to open the mailbox in EXAMINE mode, not SELECT. def select(self, mailbox='INBOX', readonly=None): if readonly is not None: name = 'EXAMINE' else: name = 'SELECT' So passing what seems to be a boolean option into the function causes unexpected circumstances in client code. Recommend that the comparison be changed to 'if readonly:'. I have verified this code exists in python2.3 and in python cvs head. ---------------------------------------------------------------------- >Comment By: Piers Lauder (pierslauder) Date: 2005-08-31 20:32 Message: Logged In: YES user_id=196212 The manual suggests that "set"ing the 'readonly' flag will disable modifications, and I agree the suggested change would produce the expected behaviour - will check in a fix... ---------------------------------------------------------------------- Comment By: Stephen Thorne (jerub) Date: 2005-08-31 15:54 Message: Logged In: YES user_id=100823 assigned to pierslauder as per abaxter's request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277098&group_id=5470 From noreply at sourceforge.net Wed Aug 31 12:48:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 03:48:15 -0700 Subject: [ python-Bugs-1277098 ] imaplib Imap.select() uses comparison to 'None' for boolean Message-ID: Bugs item #1277098, was opened at 2005-08-31 15:52 Message generated for change (Comment added) made by pierslauder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277098&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.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Stephen Thorne (jerub) Assigned to: Piers Lauder (pierslauder) Summary: imaplib Imap.select() uses comparison to 'None' for boolean Initial Comment: The imap class's method for selecting a mailbox in read only mode is subtly broken. Calling i.select('INBOX', readonly=0) will cause the imap library to open the mailbox in EXAMINE mode, not SELECT. def select(self, mailbox='INBOX', readonly=None): if readonly is not None: name = 'EXAMINE' else: name = 'SELECT' So passing what seems to be a boolean option into the function causes unexpected circumstances in client code. Recommend that the comparison be changed to 'if readonly:'. I have verified this code exists in python2.3 and in python cvs head. ---------------------------------------------------------------------- >Comment By: Piers Lauder (pierslauder) Date: 2005-08-31 20:48 Message: Logged In: YES user_id=196212 Suggested change checked in. ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2005-08-31 20:32 Message: Logged In: YES user_id=196212 The manual suggests that "set"ing the 'readonly' flag will disable modifications, and I agree the suggested change would produce the expected behaviour - will check in a fix... ---------------------------------------------------------------------- Comment By: Stephen Thorne (jerub) Date: 2005-08-31 15:54 Message: Logged In: YES user_id=100823 assigned to pierslauder as per abaxter's request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277098&group_id=5470 From noreply at sourceforge.net Wed Aug 31 13:05:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 04:05:48 -0700 Subject: [ python-Bugs-1277016 ] Sentence fragment in urlparse documentation Message-ID: Bugs item #1277016, was opened at 2005-08-31 01:57 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277016&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.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Nobody/Anonymous (nobody) Summary: Sentence fragment in urlparse documentation Initial Comment: The urlparse documentation contains this sentence fragment: "This should generally be used instead of urlparse() if the more recent URL syntax allowing parameters to be applied to each segment of the path portion of the URL (see RFC 2396)."[1] >From the context, I infer that the sentence should read something like: "This should generally be used instead of urlparse() if you do not wish to support the more recent URL syntax allowing parameters to be applied to each segment of the path portion of the URL (see RFC 2396)." ----- [1] http://www.python.org/dev/doc/devel/lib/module-urlparse.html ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-08-31 13:05 Message: Logged In: YES user_id=89016 Checked in a different fix (by appending " is wanted" to the sentence fragment). Thanks for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277016&group_id=5470 From noreply at sourceforge.net Wed Aug 31 15:50:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 06:50:04 -0700 Subject: [ python-Feature Requests-1275677 ] add a get() method to sets Message-ID: Feature Requests item #1275677, was opened at 2005-08-29 15:49 Message generated for change (Comment added) made by pitrou You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&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: None Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Raymond Hettinger (rhettinger) Summary: add a get() method to sets Initial Comment: Hi, I would like to propose a new method for the builtin set objects. Currently we have a pop() method which pops an element from the set. What I often need, though, is a method that gets an arbitrary element without removing it (because adding / removing stuff is dealt with in another part of the program). Right now the simplest way to do that is : value = iter(my_set).next() There are two problems with this: 1. it's ugly and not very intuitive 2. it is not atomic; this means if another thread updates the set, I can get a "RuntimeError: dictionary changed size during iteration" (btw, the message is slightly wrong, it should be "set" instead of "dictionary") Although the first problem is rather minor (but annoying nevertheless), the second one is a real showstopper in some cases - yes, I did encounter it for real. There is a way to avoid the second problem : value = list(my_set)[0] But of course, not only it is still ugly, but it is also highly inefficient when the set is big. So in the end I am forced to use an explicit lock around the aforementioned construct (value = iter(my_set).next()) as well as around any other piece of code that can update the set from another thread. This is tedious and error-prone, and probably a bit inefficient. So for the bottom line: it would be in some cases very useful to have an atomic get() method in addition to the pop() method on sets. (it could probably be applied to frozensets and dicts too) The implementation would probably not be very difficult, since it's the same as pop() with the removal feature removed. ;) But I'm not familiar with the Python internals. What do you think ? Regards Antoine. ---------------------------------------------------------------------- >Comment By: Antoine Pitrou (pitrou) Date: 2005-08-31 15:50 Message: Logged In: YES user_id=133955 > Those two answers suggest this RFE is unnecessary. If you > guys agree, please close. If not, I'll ponder it further. > Right now, I'm disinclined to introduce a method that I > think is awkward to use. Well, closing the request is fine for me. Although I don't think choose() would be very awkward to use, we can probably live without it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-30 22:06 Message: Logged In: YES user_id=80475 For the record, here are some research results. Java's set objects do not have a choose() method: http://java.sun.com/j2se/1.4.2/docs/api/java/util/Set.html In contrast, SETL does provide a function for extracting arbitrary elements. The empty set case is handled by returning Om which is a singleton object guaranteed not to be an element of any set. The Om value is especially useful in SETL because it can be passed upward through other functions (much in the same way that NANs can trickle through a calculation without killing it). Python has no equivalent of Om. http://www.cs.nyu.edu/~bacon/setl-doc.html#arb Core Perl only has arrays and hashes. Mathematica provides set operations on lists (union, intersection, complement). Rather than having a set specific function for extraction, list functions are used. The one providing choose-like functionality is First(). It is equivalent to indexing: a[0] http://documents.wolfram.com/mathematica/functions/First ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-30 13:47 Message: Logged In: YES user_id=80475 > > Question for everyone: Is there any known application for > > choose() that isn't met by pop()/add() irrespective of > > whether it "feels right"? [Antoine] > I don't think so indeed. [mwh] > Mmm, the "v, = s" approach hadn't occurred to me and it > seems ok. Those two answers suggest this RFE is unnecessary. If you guys agree, please close. If not, I'll ponder it further. Right now, I'm disinclined to introduce a method that I think is awkward to use. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-08-30 09:03 Message: Logged In: YES user_id=6656 Mmm, the "v, = s" approach hadn't occurred to me and it seems ok. The others are all rather horribly indirect... (and, obviously, it's not about "need"). ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-30 01:09 Message: Logged In: YES user_id=133955 Hi again, > Antoine, yes a pop()/add() combination is efficient. Ok, thanks. > IMO, > it also clear in intent, easy to write, flexible enough for > a variety of applications, the pop() is atomic, Small correction: the pop() is atomic, but the pop/add sequence is not, AFAIU ;) > Question for Antoine: Have you ever had this need with > other containers? I think I had it for a dict sometime. For lists and tuples, you can just use my_container[0] of course. But sets are often used differently than dicts IMHO. Dicts are mappings: you give a precise key and get the exact value associated with it. Sets are bags: sometimes you just want to pick an item, as you would do in a real bag, without looking inside to choose a specific item. > Since choose() would not be a > mutating method, it would also apply to frozensets. Does it > have any use there? Any appearance in a loop would be farce > since it would always return the same value (the frozenset > never mutates). The variable to which you apply the method call could reference another frozenset on the next loop iteration... Yes, it doesn't sound very frequent. > Question for everyone: Is there any known application for > choose() that isn't met by pop()/add() irrespective of > whether it "feels right"? I don't think so indeed. (it would be the case if the API guaranteed atomicity in the case of single bultin method calls like choose()) > For applications other than Michael's, we won't know the > size of the set in advance. Are there any examples of using > choose() that won't have to have ugly EAFP or LBYL code to > handle the case where the set is empty? First, sometimes you know the set is non-empty without knowing its size in advance (for example you are inside a big block beginning with "if len(my_set)"). Second, error catching is still needed with other alternatives (you either have to catch KeyError when doing s.pop(), or StopIteration when doing iter(s).next()). > Rather than a method just for sets, is it a more appropriate > solution to have a generic function that takes any iterable > and returns its first element: Well, I thought global builtin functions were less favoured than methods. But this doesn't sound stupid. On the other hand, generic functions are less easy to find about (usually if I want to have the set API, I type help(set) in a Python shell which I always have open. But there is no quick way to have a list of the builtin functions that can apply to iterables (*)). In my experience, I often forget about the generic builtin functions that come with Python - maybe that's just me. (*) if there was a base type "iterable" with the generic method first() defined on it, as well as some of the other functions defined in the itertools module, it would probably be more elegant and more frequently used. Anyway, if the concern with builtin types is to avoid bloating the API, then I admit that it's a fair concern and that the motivation to add the choose() method might indeed not be convincing enough. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-30 00:30 Message: Logged In: YES user_id=80475 Exploratory questions: Michael, if you know there is only one element in a set, do you really need a custom method just to extract it? There are so many other ways. Given s=set([7]): 1) x = list(s)[0] 2) x = s.pop() 3) x, = s 4) x = max(s) yada yada yada Antoine, yes a pop()/add() combination is efficient. IMO, it also clear in intent, easy to write, flexible enough for a variety of applications, the pop() is atomic, and the approach also works with other mutable containers (dicts, lists, deques). Question for Antoine: Have you ever had this need with other containers? For instance, how do you find an arbitrary key in a dictionary without popping, iterating, or listing it? Question for everyone: Since choose() would not be a mutating method, it would also apply to frozensets. Does it have any use there? Any appearance in a loop would be farce since it would always return the same value (the frozenset never mutates). Question for everyone: Is there any known application for choose() that isn't met by pop()/add() irrespective of whether it "feels right"? For applications other than Michael's, we won't know the size of the set in advance. Are there any examples of using choose() that won't have to have ugly EAFP or LBYL code to handle the case where the set is empty? Rather than a method just for sets, is it a more appropriate solution to have a generic function that takes any iterable and returns its first element: def getfirst(it): for elem in it: return elem raise ValueError('iterator is empty') A function like this would work with almost anything: first(dict(a=1, b=2)) first(set([1, 2])) first([1,2]) first(open('myfile.txt')) . . . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-08-29 22:42 Message: Logged In: YES user_id=6656 _My_ use case for something like this is applying a series of constraints as set intersections until the set has one element; then I want to know what that element *is*. I could probably use .pop(), but it feels wrong, and I know I can (and indeed do) do iter(theSet).next() but that's obscure. ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 21:16 Message: Logged In: YES user_id=133955 > When choosing a ready object, you pop it to unready > because you're using it -- put it back in if the current use > won't cause blocking, or when that use finishes. That's not exactly my semantics (objects remain ready until they explicitly tell the contrary: for example a queue remains ready until it becomes empty), but I can live with a pop() / add() sequence provided it is efficient. Is it ? Otherwise I may go for "elem = iter(my_set).next()". Thanks for the very prompt answers, btw :) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-08-29 21:07 Message: Logged In: YES user_id=764593 This does look like pop might be a better choice. When choosing a ready object, you pop it to unready because you're using it -- put it back in if the current use won't cause blocking, or when that use finishes. When choosing a waiting ready thread, either the thread is no longer ready (so put it back in waiting, but you don't want it in ready), or it runs (so it should no longer be in waiting). ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2005-08-29 20:31 Message: Logged In: YES user_id=133955 Hi, Thanks for the detailed reply. So, atomicity cannot be guaranteed. I understand that (you might tell it to the Twisted folks by the way, because as far as I've seen some of their code relies on list operations being atomic in CPython ;-)). Remains the simplicity argument. As for the first objection: my set is mutated in the loop in ways that I cannot predict (because each element in the set points me in turn to a user-defined callback that will often alter the set ;-)). That explains why it *is* useful to get the "first" element repeatedly: the "first" element changes very often. As for the use case : I'm writing a small cooperative multithread package using generators (mostly for fun, but I'll be glad if it pleases others too): https://developer.berlios.de/projects/tasklets/ Scheduling is based on "wait objects": when a wait object becomes ready, it is added to the set of ready objects and the main loop takes an element from this set and asks it for one of the threads waiting on the object. It is the set I'm talking about ;) Sometimes the readiness of one of those objects can be changed from another thread (for now I'm using a helper thread for timers, and perhaps also for other things in the future - IO, wxWidgets integration, etc.). The main loop is in the Switcher.run() method towards the end of the following file: http://svn.berlios.de/viewcvs/tasklets/trunk/softlets/core.py?view=markup As you see, I actually do a "for" on the set, but I always break of the "for" loop after the first iteration... Which is not very elegant and understandable for the reader. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-29 19:10 Message: Logged In: YES user_id=80475 We've looked at a choose() method a couple of times and rejected it. Since the method gets an arbitrary element, it might as well get the first one it sees. But that is of little use in a loop (when do you ever need to get the same object over and over again?). Also, a choose method() would need to raise a KeyError if the set if emtpy and/or provide a default argument like dict.get() does. This complicates the heck out of using it. Put the two together and the idea loses any charm. Also, for mutable sets, a better approach is to pop() elements from the set and add them back when you're done with them. I'm not too concerned about atomicity. For one, that is almost never a good guide to API design. Second, it is implementation dependent (i.e. no guarantees for PyPy or Jython). Three, it generally indicates a problem in your design (if the set could mutate smaller during a thread accessing the set, then you have a race condition where the set could shrink to zero or not). Four, the right way to deal with atomicity issues is to use locks or control access via Queue. I do understand that basic motivation (I have a set, now how do I a representative element) but find the proposal lacking. It just doesn't do much for us. BTW, please post your use case (in a condensed form that gets to the essentials of why you think this method is needed).. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1275677&group_id=5470 From noreply at sourceforge.net Wed Aug 31 18:11:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 09:11:48 -0700 Subject: [ python-Bugs-1235646 ] codecs.StreamRecoder.next doesn't encode Message-ID: Bugs item #1235646, was opened at 2005-07-10 18:55 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Wangnick (wangnick) Assigned to: M.-A. Lemburg (lemburg) Summary: codecs.StreamRecoder.next doesn't encode Initial Comment: Codecs.StreamRecode.next does't encode the data it gets from self.reader.next. This breaks the "for line in codecs.EncodedFile(...)" idiom. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-08-31 18:11 Message: Logged In: YES user_id=89016 Here's a simple patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470 From noreply at sourceforge.net Wed Aug 31 18:52:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 09:52:19 -0700 Subject: [ python-Bugs-1212195 ] str.lower() to have an IMPORTANT NOTE or it's for magicians Message-ID: Bugs item #1212195, was opened at 2005-05-31 20:56 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&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: None Status: Open Resolution: None Priority: 5 Submitted By: Nikos Kouremenos (nkour) Assigned to: M.-A. Lemburg (lemburg) Summary: str.lower() to have an IMPORTANT NOTE or it's for magicians Initial Comment: lower() {maybe others} should mention that if used with string object [not unicode object] it's likely the that encoding will change unde some locales [eg pl_PL makes it from utf8 to latin2]!! or this hsould be put in the beginning of the doc in str as a general WARNING/NOTE: ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-08-31 18:52 Message: Logged In: YES user_id=89016 I'd like to see an example that shows this change from utf8 to latin2. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-06-26 00:05 Message: Logged In: YES user_id=174455 I tried to come up with a doc-patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1227545&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-06-02 13:48 Message: Logged In: YES user_id=38388 A doc-patch would be nice. I don't like the general situation either. Unicode doesn't behave like this and I don't think string.lower() and .upper() should either, but there are users out there who think differently, so we might want to add a parameter which then allows modifying the type of mapping: string.lower(map='ascii') string.upper(map='latin-1') etc. Just an idea. PS: I'll be offline for two weeks now, so don't expect any more comments before then. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 23:43 Message: Logged In: YES user_id=80475 Mark, do you have any thoughts on this one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&group_id=5470 From noreply at sourceforge.net Wed Aug 31 18:56:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 09:56:52 -0700 Subject: [ python-Bugs-1200686 ] SyntaxError raised on win32 for correct files Message-ID: Bugs item #1200686, was opened at 2005-05-12 16:19 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&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: None Priority: 5 Submitted By: Federico Di Gregorio (fog) Assigned to: Nobody/Anonymous (nobody) Summary: SyntaxError raised on win32 for correct files Initial Comment: Try to import the attached file (dt.py) on Windows with Python 2.4 or 2.4.1 and you'll get a SyntaxError (the file was written a long time ago, and worked perfectly well on Python 2.1, 2.2 and 2.3.) The same does not happen when importing the same module on Linux (tested with 2.4 and 2.4.1). When the module imports fine you'll get an ImportError (don't want to attach all dependencies here) but the SyntaxError comes before that. Also note that compiling the file with compiler.compileFile("dt.py") generates a perfectly good .pyc file that can be later imported just fine (tested with 2.4 and 2.4.1 on Windows). ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-08-31 18:56 Message: Logged In: YES user_id=89016 Copying codecs.py from current CVS (2.4 branch) over your codecs.py (making a backup first) should be sufficient to test this. You can this version from http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/Lib/codecs.py?rev=1.35.2.9 ---------------------------------------------------------------------- Comment By: Julien Sagnard (julien_sagnard) Date: 2005-07-20 11:37 Message: Logged In: YES user_id=1181710 It's ok if I remove coding declaration. I have no access to current cvs, but if someone send me a zip with latest version, I can try it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-07-19 18:19 Message: Logged In: YES user_id=89016 This bug should be fixed in the current CVS version. So, can you retry with current CVS? As a workaround you might also want to remove the PEP 263 coding declaration if you don't have any special character in your file. ---------------------------------------------------------------------- Comment By: Julien Sagnard (julien_sagnard) Date: 2005-07-19 18:05 Message: Logged In: YES user_id=1181710 I have a similar problem with an other file (log.py). On my computer ( Windows 2000 ) this 2 files ( log.py and dt.py ) works with python 2.4 but raise a syntax error on python 2.4.1 : D:\dvt\tmp\bug2_4_1>python -c "import log" Traceback (most recent call last): File "", line 1, in ? File "D:\dvt\tmp\bug2_4_1\log.py", line 356 w = 72 ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-05-18 16:15 Message: Logged In: YES user_id=86307 I'm fairly sure this is caused by the bug described here: www.python.org/sf/1175396 The module imports without syntax error on my Windows system (with a patched codecs.py to work around the above bug). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470 From noreply at sourceforge.net Wed Aug 31 19:18:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 10:18:36 -0700 Subject: [ python-Bugs-1189248 ] Seg Fault when compiling small program Message-ID: Bugs item #1189248, was opened at 2005-04-25 07:00 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189248&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: Out of Date Priority: 5 Submitted By: Reginald B. Charney (rcharney) Assigned to: Nobody/Anonymous (nobody) Summary: Seg Fault when compiling small program Initial Comment: I am using SuSE 9.2. When trying to compile/interpret the attached file, the python interpreter seg faults with no other information. Please note: the attached test file does not end in a new line. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-08-31 19:18 Message: Logged In: YES user_id=89016 Martins patch to pythonrun.c (2.216/2.211.2.2) should have finally fixed this completely. On Linux I get "SyntaxError: 'unknown encoding: evilascii' (evil.py, line 1)". Closing as out of date. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 13:45 Message: Logged In: YES user_id=1188172 I believe it is fixed, too... can't reproduce here. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-25 09:56 Message: Logged In: YES user_id=6656 I think this is fixed in Python 2.4.1... what version are you using? ---------------------------------------------------------------------- Comment By: Reginald B. Charney (rcharney) Date: 2005-04-25 08:42 Message: Logged In: YES user_id=411372 It turns out that the seg fault was caused by the first line of the program: # coding: evil It seems that specifying an invalid character encoding causes a seg fault. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189248&group_id=5470 From noreply at sourceforge.net Wed Aug 31 22:10:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 13:10:27 -0700 Subject: [ python-Bugs-1277718 ] Lambda and deepcopy Message-ID: Bugs item #1277718, was opened at 2005-08-31 14:10 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=1277718&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Joshua Ginsberg (jaginsberg) Assigned to: Nobody/Anonymous (nobody) Summary: Lambda and deepcopy Initial Comment: Howdy -- I have a class that has an attribute that is a dictionary that contains an object that has a kword argument that is a lambda. Confused yet? Simplified example: import copy class Foo: def __init__(self, fn=None): self.fn = fn class Bar: d = {'foobar': Foo(fn=lambda x: x*x)} def cp(self): self.xerox = copy.deepcopy(self.d) When I execute: b = Bar() b.cp() Using Python version: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin I get: Traceback (most recent call last): File "", line 1, in ? File "", line 5, in cp File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py", line 179, in deepcopy y = copier(x, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py", line 270, in _deepcopy_dict y[deepcopy(key, memo)] = deepcopy(value, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py", line 179, in deepcopy y = copier(x, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py", line 307, in _deepcopy_inst state = deepcopy(state, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py", line 179, in deepcopy y = copier(x, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py", line 270, in _deepcopy_dict y[deepcopy(key, memo)] = deepcopy(value, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py", line 206, in deepcopy y = _reconstruct(x, rv, 1, memo) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy.py", line 338, in _reconstruct y = callable(*args) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy_reg.py", line 92, in __newobj__ return cls.__new__(cls, *args) TypeError: function() takes at least 2 arguments (0 given) I've googled for deepcopy and lambda and found somebody else asking the same question on a LUG somewhere, but they gave no advice and nobody else seems to have run into this. Any ideas on what the problem is/how to get around it? Thanks! -jag ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1277718&group_id=5470 From noreply at sourceforge.net Wed Aug 31 22:43:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 13:43:59 -0700 Subject: [ python-Bugs-1212195 ] str.lower() to have an IMPORTANT NOTE or it's for magicians Message-ID: Bugs item #1212195, was opened at 2005-05-31 20:56 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&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: None >Status: Closed Resolution: None Priority: 5 Submitted By: Nikos Kouremenos (nkour) Assigned to: M.-A. Lemburg (lemburg) Summary: str.lower() to have an IMPORTANT NOTE or it's for magicians Initial Comment: lower() {maybe others} should mention that if used with string object [not unicode object] it's likely the that encoding will change unde some locales [eg pl_PL makes it from utf8 to latin2]!! or this hsould be put in the beginning of the doc in str as a general WARNING/NOTE: ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-31 22:43 Message: Logged In: YES user_id=38388 Closing the bug report. Please see follow-ups on the doc-patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-31 18:52 Message: Logged In: YES user_id=89016 I'd like to see an example that shows this change from utf8 to latin2. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-06-26 00:05 Message: Logged In: YES user_id=174455 I tried to come up with a doc-patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1227545&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-06-02 13:48 Message: Logged In: YES user_id=38388 A doc-patch would be nice. I don't like the general situation either. Unicode doesn't behave like this and I don't think string.lower() and .upper() should either, but there are users out there who think differently, so we might want to add a parameter which then allows modifying the type of mapping: string.lower(map='ascii') string.upper(map='latin-1') etc. Just an idea. PS: I'll be offline for two weeks now, so don't expect any more comments before then. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 23:43 Message: Logged In: YES user_id=80475 Mark, do you have any thoughts on this one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&group_id=5470 From noreply at sourceforge.net Wed Aug 31 22:58:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 13:58:12 -0700 Subject: [ python-Bugs-1235646 ] codecs.StreamRecoder.next doesn't encode Message-ID: Bugs item #1235646, was opened at 2005-07-10 18:55 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Wangnick (wangnick) >Assigned to: Walter D?rwald (doerwalter) Summary: codecs.StreamRecoder.next doesn't encode Initial Comment: Codecs.StreamRecode.next does't encode the data it gets from self.reader.next. This breaks the "for line in codecs.EncodedFile(...)" idiom. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-31 22:58 Message: Logged In: YES user_id=38388 Looks good, Walter. Please check it in. Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-31 18:11 Message: Logged In: YES user_id=89016 Here's a simple patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470 From noreply at sourceforge.net Wed Aug 31 23:55:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 14:55:09 -0700 Subject: [ python-Bugs-1202493 ] RE parser too loose with {m,n} construct Message-ID: Bugs item #1202493, was opened at 2005-05-15 23:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&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: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Gustavo Niemeyer (niemeyer) Summary: RE parser too loose with {m,n} construct Initial Comment: This seems wrong to me: >>> re.match("(UNIX{})", "UNIX{}").groups() ('UNIX',) With no numbers or commas, "{}" should not be considered special in the pattern. The docs identify three numeric repetition possibilities: {m}, {m,} and {m,n}. There's no description of {} meaning anything. Either the docs should say {} implies {1,1}, {} should have no special meaning, or an exception should be raised during compilation of the regular expression. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-31 23:55 Message: Logged In: YES user_id=1188172 Any more objections against treating "{}" as literal? The impact on existing code will be minimal, as I presume no one will write "{}" in a RE instead of "{1,1}" (well, who writes "{1,1}" anyway...). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 21:10 Message: Logged In: YES user_id=1188172 Then, I think, we should follow Perl's behaviour and treat "{}" as a literal, just like every other brace construct that isn't a repeat specifier. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-03 20:46 Message: Logged In: YES user_id=80475 Hmm, it looks like they cannot be treated differently without breaking backwards compatability. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 20:00 Message: Logged In: YES user_id=1188172 Raymond said that braces should always be considered special. This includes constructs like "{(?P.*)}" which the string module uses, and which would be a syntax error then. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-03 17:13 Message: Logged In: YES user_id=44345 Can you elaborate? I fail to see what the string module has to do with the re module. Can you give an example of code that would break? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 10:01 Message: Logged In: YES user_id=1188172 I just realized that e.g. the string module uses unescaped braces, so I think we should not become overly strict as it would break much code... Perhaps the original patch (sre-brace-diff) is better... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-02 13:16 Message: Logged In: YES user_id=44345 In the absence of strong technical reasons, I'd vote to do what Perl does. I believe the assumption all along has been that most people coming to Python who already know how to use regular expressions are Perl programmers. It wouldn't seem to make sense to throw little land mines in their paths. I realize that explicit is better than implicit, but practicality beats purity. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 23:32 Message: Logged In: YES user_id=1188172 Okay. Attaching patch which does that. BTW, these things are currently allowed too (treated as literals): "{" "{x" "{x}" "{x,y}" "{1,x}" etc. The patch changes that, too. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 23:07 Message: Logged In: YES user_id=80475 I prefer Skip's third option, raising an exception during compilation. This is an re syntax error. Treat it the same way that we handle similar situations with regular Python: >>> a[] SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 22:30 Message: Logged In: YES user_id=1188172 So, should a {} raise an error, or warn like in Ruby? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-01 22:25 Message: Logged In: YES user_id=80475 IMO, the simplest rule is that braces always be considered special. This accommodates future extensions, simplifies the re compiler, and makes it easier to know what needs to be escaped. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 18:54 Message: Logged In: YES user_id=1188172 It's interesting what other RE implementations do with this ambiguity: Perl treats {} as literal in REs, as Skip proposes. Ruby does, too, but issues a warning about } being unescaped. GNU (e)grep v2.5.1 allows a bare {} only if it is at the start of a RE, but matches it literally then. GNU sed v4.1.4 does never allow it. GNU awk v3.1.4 is gracious and acts like Perl. Attached is a patch that fixes this behaviour in the appearing "common sense". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470 From noreply at sourceforge.net Wed Aug 31 23:59:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Aug 2005 14:59:28 -0700 Subject: [ python-Bugs-691733 ] Let assign to as raise SyntaxWarning as well Message-ID: Bugs item #691733, was opened at 2003-02-23 18:08 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=691733&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.5 Status: Open Resolution: None Priority: 2 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Let assign to as raise SyntaxWarning as well Initial Comment: according to the Python Language Reference Manual: > In some future version of Python, the identifiers > as and None will both become keywords. Hence, it seems natural to me to raise a SyntaxWarning when assigning to either of these. However, the current Python implementation doesn't: 103 >>> None="foo" <stdin>:1: SyntaxWarning: assignment to None 104 >>> as="foo" 105 >>> For consistency and cleanliness, assignment to 'as' should raise a SyntaxWarning as well. Currently, it's possible to not know it'll be a keyword and use it as a variable; people shouldn't, so a SyntaxWarning would be good. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-31 23:59 Message: Logged In: YES user_id=1188172 For Py2.5, "with" and "as" will become keywords. However, that will need "from __future__ import with_statement". So I suggest to raise SyntaxWarning in 2.5 without this statement if with or as are used as names. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 13:23 Message: Logged In: YES user_id=1188172 This may be too late if as becomes a keyword in the new with/do/whatever-statement... ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2003-02-23 18:21 Message: Logged In: YES user_id=13298 I'm not sure whether this should be considered as a feature. I'd call it a minor wart... I'm also not sure about the category, is this 'Python interpreter core' or am I right with 'parser/compiler'? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=691733&group_id=5470