[ python-Bugs-1072182 ] bad arg type to isspace in struct module
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
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1239186 ] Install Error: "cannot compute sizeof (int), 77"
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1234473 ] configure: error: cannot compute sizeof (int), 77
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1263635 ] type() and isinstance() do not call __getattribute__
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1234674 ] filecmp.cmp's "shallow" option
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1234674 ] filecmp.cmp's "shallow" option
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-849662 ] reading shelves is really slow
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: ><>< ([EMAIL PROTECTED] 534) PYTHONPATH=../../../COMMON.DEVEL/Tools/python/lib.linux- i686-2.3 python Konvertierung/entsch_pass2.py HI69228 x HR all_idx2.shelve
[ python-Bugs-1261659 ] Tutorial doesn't cover * and ** function calls
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1273892 ] Encoding memory problem.
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1273892 ] Encoding memory problem.
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1261229 ] __new__ is class method
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1273892 ] Encoding memory problem.
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1234674 ] filecmp.cmp's "shallow" option
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1261229 ] __new__ is class method
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1274069 ] bz2module.c compiler warning
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1274069 ] bz2module.c compiler warning
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1274324 ] 'setup.py install' fail on linux from read-only storage
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
