[ python-Bugs-1681762 ] too long string causes segmentation fault
Bugs item #1681762, was opened at 2007-03-15 23:12 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681762&group_id=5470 Please note that this 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 Private: No Submitted By: L (llukas11) Assigned to: Martin v. Löwis (loewis) Summary: too long string causes segmentation fault Initial Comment: consider running this on machine with 16GB of ram: line = "x" for i in range(40): line = line + line print len(line) and it's output: 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864 134217728 268435456 536870912 1073741824 -2147483648 Segmentation fault [EMAIL PROTECTED] 0.1.x]$ python Python 2.4.4 (#1, Oct 23 2006, 13:58:18) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 I'll can try to chceck if it fails with python 2.5 but I need to compile one. I have stumlbed on this bug when reading line by line 3GB file and forgetting to clear string after I processed data. -- Comment By: Žiga Seilnacht (zseil) Date: 2007-03-16 11:17 Message: Logged In: YES user_id=1326842 Originator: NO This looks like a duplicate of bug #1526585: http://www.python.org/sf/1526585 That bug was fixed in Python 2.5, but it didn't get backported to the 2.4 branch (string_concatenate() in ceval.c is still missing an overflow check). -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 08:30 Message: Logged In: YES user_id=849994 Originator: NO Martin, do you think the Py_ssize_t changes prevent this in Py2.5? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681762&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1682241 ] Problems with urllib2 read()
Bugs item #1682241, was opened at 2007-03-16 17:00 Message generated for change (Comment added) made by lucas_malor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682241&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lucas Malor (lucas_malor) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with urllib2 read() Initial Comment: urllib2 objects opened with urlopen() does not have the method seek() as file objects. So reading only some bytes from opened urls is pratically forbidden. An example: I tried to open an url and check if it's a gzip file. If IOError is raised I read the file (to do this I applied the #1675951 patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1675951&group_id=5470&atid=305470 ) But after I tried to open the file as gzip, if it's not a gzip file the current position in the urllib object is on the second byte. So read() returns the data from the 3rd to the last byte. You can't check the header of the file before storing it on hd. Well, so what is urlopen() for? If I must store the file by url on hd and reload it, I can use urlretrieve() ... -- >Comment By: Lucas Malor (lucas_malor) Date: 2007-03-20 09:59 Message: Logged In: YES user_id=1403274 Originator: YES > If you need to seek, you can wrap the file-like object in a > StringIO (which is what urllib would have to do internally > [...] ) I think it's really a bug, or at least a non-pythonic method. I use the method you wrote, but this must be done manually, and I don't know why. Actually without this "trick" you can't handle url and file objects together as they don't work in the same manner. I think it's not too complicated using the internal StringIO object in urllib class when I must seek() or use other file-like methods. > You can check the type of the response content before you try > to uncompress it via the Content-Encoding header of the > response It's not a generic solution (thanks anyway for suggested solutions :) ) -- Comment By: Zacherates (maenpaa) Date: 2007-03-20 03:43 Message: Logged In: YES user_id=1421845 Originator: NO I'd contend that this is not a bug: * If you need to seek, you can wrap the file-like object in a StringIO (which is what urllib would have to do internally, thus incurring the StringIO overhead for all clients, even those that don't need the functionality). * You can check the type of the response content before you try to uncompress it via the Content-Encoding header of the response. The meta-data is there for a reason. Check http://www.diveintopython.org/http_web_services/gzip_compression.html for a rather complete treatment of your use-case. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682241&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1684254 ] regression in webbrowser command line parsing
Bugs item #1684254, was opened at 2007-03-20 12: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=1684254&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: regression in webbrowser command line parsing Initial Comment: With Python 2.4 it was common to use BROWSER environment variables like: BROWSER="firefox '%s' &" to launch a browser. The apostrophes around %s are required to escape special characters in the URL (because the command is launched using os.system, which uses a shell), and & at the end is required to not block GUI applications. However, in Python 2.5 it uses the subprocess module, and the example above doesn't work. It tries to open `firefox 'URL' &` literally, which causes Firefox to open URIs like file:///path/to/current/directory/'URL'. Attached a patch that fixes the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684254&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1684603 ] Add tail recursion
Feature Requests item #1684603, was opened at 2007-03-20 18:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1684603&group_id=5470 Please note that this 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 Private: No Submitted By: Tommy Nordgren (unclezeb) Assigned to: Nobody/Anonymous (nobody) Summary: Add tail recursion Initial Comment: Consider the following code: def fac(m): def iter(acc,n): if n <= 0 : return acc else: return iter(acc * n, n - 1) return iter(1,m) #When called wtih a large parameter, you get exceed the recursion limit fac(1) In a future release, I suggest updating the interpreter and byte code compiler to handle tail recursion properly as in scheme. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1684603&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1684603 ] Add tail recursion
Feature Requests item #1684603, was opened at 2007-03-20 12:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1684603&group_id=5470 Please note that this 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.6 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Tommy Nordgren (unclezeb) Assigned to: Nobody/Anonymous (nobody) Summary: Add tail recursion Initial Comment: Consider the following code: def fac(m): def iter(acc,n): if n <= 0 : return acc else: return iter(acc * n, n - 1) return iter(1,m) #When called wtih a large parameter, you get exceed the recursion limit fac(1) In a future release, I suggest updating the interpreter and byte code compiler to handle tail recursion properly as in scheme. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-20 14:05 Message: Logged In: YES user_id=80475 Originator: NO This sort of optimization is one of the many that aren't possible without changing the semantics of the language. Recursive calls use a LOAD_GLOBAL in the function to reference itself. The value of that global is subject to change outside the body of the function. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1684603&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1656538 ] dict(key,values) initializer
Feature Requests item #1656538, was opened at 2007-02-09 21:05 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1656538&group_id=5470 Please note that this 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.6 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: George Sakkis (gsakkis) Assigned to: Nobody/Anonymous (nobody) Summary: dict(key,values) initializer Initial Comment: Far too often I use the idiom dict(zip(keys,values)), or the same with izip. How does letting dict take two positional arguments sound ? Pros: - Pretty obvious semantics, no mental overhead to learn and remember it. - More concise (especially if one imports itertools just to use izip). - At least as efficient (and probably more) as the current alternatives. - Backwards compatible. George -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-20 14:08 Message: Logged In: YES user_id=80475 Originator: NO Sorry, the number of options for the dict constructor is already at its outer limit. No need to further complicate the situation in order to save just five or six characters in the invocation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1656538&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds
Bugs item #1683368, was opened at 2007-03-18 23:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 16:54 Message: Logged In: YES user_id=6380 Originator: NO Here's a stricter version. Unfortunately it breaks a couple of standard modules; this is a confirmation of my doubts whether the style of cooperative super calling of __init__ that you use is really the most common or "best practice". So far I have only fixed string.py (which would otherwise prevent extensions from being built); I haven't looked into why the other tests fail: test_array, test_cpickle, test_descr, test_pickle (and maybe more?). My conclusion: this would probably break too much code to be worth it. So I'll have to revert to the previous version. But anyway, here it is for your perusal. File Added: new_init_strict.patch -- Comment By: Blake Ross (blakeross) Date: 2007-03-19 21:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(cls) a(1) (minor typo in the patch: "solution it" -> "solution is") -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch -- Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be i
[ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds
Bugs item #1683368, was opened at 2007-03-18 23:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 17:24 Message: Logged In: YES user_id=6380 Originator: NO I should mention that if we can't get the strict version of this in 2.6, we should be able to get it into 3.0. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 16:54 Message: Logged In: YES user_id=6380 Originator: NO Here's a stricter version. Unfortunately it breaks a couple of standard modules; this is a confirmation of my doubts whether the style of cooperative super calling of __init__ that you use is really the most common or "best practice". So far I have only fixed string.py (which would otherwise prevent extensions from being built); I haven't looked into why the other tests fail: test_array, test_cpickle, test_descr, test_pickle (and maybe more?). My conclusion: this would probably break too much code to be worth it. So I'll have to revert to the previous version. But anyway, here it is for your perusal. File Added: new_init_strict.patch -- Comment By: Blake Ross (blakeross) Date: 2007-03-19 21:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(cls) a(1) (minor typo in the patch: "solution it" -> "solution is") -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch -- Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using
[ python-Bugs-471432 ] __cdecl / __stdcall unspecified in *.h
Bugs item #471432, was opened at 2001-10-15 12:18
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=471432&group_id=5470
Please note that this 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
Private: No
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Mark Hammond (mhammond)
Summary: __cdecl / __stdcall unspecified in *.h
Initial Comment:
Currently, the win32 function call convention
(__stdcall vs __cdecl) is never specified in the
function prototypes contained in the .h header files.
The call convention is therefore left up to the
configuration of the compiler incluing the header files
(__cdecl by default on VC++).
However, there are situations in which the compiler
default call convention must be set to __stdcall (/Gz
option on VC++'s cl.exe), and this makes the link fail;
until __cdecl keywords are manually insterted in the
Python.h function prototypes required for linking.
[For instance, /Gz is required when using typedef
definitions on function pointers, later passed as
arguments on __stdcall functions (the default on
Microsoft/commercial libraries)].
Besides, Microsoft recommands, it the VC++
documentation, that the __stdcall convention be used
by default for function with fixed numbers of arguments
(smaller code size and better performances); __cdecl
being limited for use with functions with variable
number of args ('...').
A solution would consist in defining:
#ifdef _MS_VER
#define FIXARGCALL __stdcall
#define VARARGCALL __cdecl
#else
...
#endif
and sticking FIXARGCALL / VARARGCALL in front of all
DLL_IMPORT(), macro calls associated to a an exported
function prototype, across all Python .h files.
Frederic Giacometti
--
>Comment By: Brett Cannon (bcannon)
Date: 2007-03-20 15:05
Message:
Logged In: YES
user_id=357491
Originator: NO
This is a rather old bug. =) If no one cares to fix this then it should
be closed.
--
Comment By: Frederic Giacometti (giacometti)
Date: 2001-10-16 10:19
Message:
Logged In: YES
user_id=93657
The fault is not in the other libraries.
In MS Windows, 'well-behaved' libraries define explicitely
the calling conventions for each function in their header
file. This is all.
There's nobody's guts loosely hanging out in this ;).
FG
--
Comment By: Tim Peters (tim_one)
Date: 2001-10-15 20:00
Message:
Logged In: YES
user_id=31435
I guess my first question is, if library X needs something
other than the default, why isn't it X's responsibility to
force *their* non-default behavior where needed? After
all, they're the oddballs. Some days I get real tired of
cleaing up after everyone else's loose bowels <0.9 wink>.
--
Comment By: Mark Hammond (mhammond)
Date: 2001-10-15 18:45
Message:
Logged In: YES
user_id=14198
This does make sense to me, and I have even been bitten by
it.
There are some strange libraries out there that need to be
compiled with a different calling convention than the
default. Trying to extend Python with such a library can
be difficult. Having the calling convention specified in
the prototypes would solve the problem.
I have never been brave enough to do it, given the small
number of times it has been reported as a problem.
However, I would be happy to help come up with a reasonable
scheme.
--
Comment By: Frederic Giacometti (giacometti)
Date: 2001-10-15 12:46
Message:
Logged In: YES
user_id=93657
As far as MS Windows / dll stuff is concerned, you're
already swimming in non-C-ANSI fishtank anyway (e.g.
DLL_IMPORT() macros...).
Just try to keep the right fishes in the tank :))
FG
--
Comment By: Tim Peters (tim_one)
Date: 2001-10-15 12:34
Message:
Logged In: YES
user_id=31435
Mark, does this make sense to you? Any notion that we
*have* to add non-standard decorations seems inherently
fishy to me.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=471432&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1684811 ] modindex.html builds incorrectly in Python 3
Bugs item #1684811, was opened at 2007-03-20 19:14 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=1684811&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: modindex.html builds incorrectly in Python 3 Initial Comment: Running "make distclean; make" in Python 3's Doc/ directory (as of r54467) leaves me with a content-less modindex.html. The header and footer are present, but there's no list of modules. The same steps on trunk/ (SVN HEAD) produce the expected module list. The mkmodindex step reports "0 index nodes". Watching the lines that mkmodindex:main() parses, none of them are related to modules (in the correct format or otherwise). I've attached a copy of the bad modindex.html that "make" generated. Also attached is a patch that allows Doc/tools/ to work with Python 3 (which it doesn't as of r54467). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684811&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1684811 ] modindex.html builds incorrectly in Python 3
Bugs item #1684811, was opened at 2007-03-20 19:14 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684811&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: modindex.html builds incorrectly in Python 3 Initial Comment: Running "make distclean; make" in Python 3's Doc/ directory (as of r54467) leaves me with a content-less modindex.html. The header and footer are present, but there's no list of modules. The same steps on trunk/ (SVN HEAD) produce the expected module list. The mkmodindex step reports "0 index nodes". Watching the lines that mkmodindex:main() parses, none of them are related to modules (in the correct format or otherwise). I've attached a copy of the bad modindex.html that "make" generated. Also attached is a patch that allows Doc/tools/ to work with Python 3 (which it doesn't as of r54467). -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-20 19:15 Message: Logged In: YES user_id=1344176 Originator: YES File Added: doc_tools.patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684811&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-578180 ] Explain how to subclass Exception
Bugs item #578180, was opened at 2002-07-06 11:58 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=578180&group_id=5470 Please note that this 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: Out of Date Priority: 5 Private: No Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: Explain how to subclass Exception Initial Comment: The contract of subclasses wrt __init__() and self.args is undocumented. -- >Comment By: Brett Cannon (bcannon) Date: 2007-03-20 17:21 Message: Logged In: YES user_id=357491 Originator: NO The docs for the 'exception' module covers this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=578180&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-546196 ] extend namespace docs to cover LOAD_NAME
Bugs item #546196, was opened at 2002-04-19 09:40 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=546196&group_id=5470 Please note that this 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: Out of Date Priority: 5 Private: No Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: extend namespace docs to cover LOAD_NAME Initial Comment: Assuming that Python continues to use LOAD_NAME, then the reference manual ought to describe this strange beast. -- >Comment By: Brett Cannon (bcannon) Date: 2007-03-20 17:23 Message: Logged In: YES user_id=357491 Originator: NO 'dis' modules bytecode docs covers LOAD_NAME. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=546196&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-586680 ] -S hides standard dynamic modules
Bugs item #586680, was opened at 2002-07-25 12:59 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586680&group_id=5470 Please note that this 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: Platform-specific >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: -S hides standard dynamic modules Initial Comment: This only applies when os.name == 'posix'. Running an un-installed build of Python with the -S option causes the directory containing the standard dynamically-built modules not to be placed on sys.path. The build/lib.- / directory containing those modules is added to sys.path by site.py rather than getpath.c, even though those modules are needed. This includes many modules on most Unix systems: array dbmmath regex termios audioopdl md5 resource _testcapi binascii errno mmap rgbimgtime bsddb fcntl mpz rotor timing cmath fpectl nis select_tkinter _codecsgdbm operator sha unicodedata cPicklegrpparser_socket _weakref crypt _hotshot pcre _ssl xreadlines cStringIO _hotshot pwd strop zlib _curses_panel linuxaudiodev pyexpat struct _curses_localereadline syslog Perhaps the best way to fix this is to add the equivalent code to getpath.c. The relevant stanza in site.py is headed by a comment saying "especially for Guido". -- >Comment By: Brett Cannon (bcannon) Date: 2007-03-20 17:24 Message: Logged In: YES user_id=357491 Originator: NO We have lived this long without changing this that I don't think this needs fixing. Requiring the use of site.py when running from a build from a repository checkout seems totally reasonable to me. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586680&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-587011 ] IBCarbon module
Bugs item #587011, was opened at 2002-07-26 06:41 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=587011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Feature Request >Status: Closed >Resolution: Out of Date Priority: 3 Private: No Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: IBCarbon module Initial Comment: Donovan Preston donated an IBCarbon module, that allows Interface Builder (in Carbon mode) to be used for creating GUIs for Python scripts. This module should be incorporated in the Carbon package. -- >Comment By: Brett Cannon (bcannon) Date: 2007-03-20 17:26 Message: Logged In: YES user_id=357491 Originator: NO The coercion didn't work. =) Plus no IBCarbon module is even listed in the module index. Closing as "out of date". -- Comment By: Jack Jansen (jackjansen) Date: 2002-08-05 15:10 Message: Logged In: YES user_id=45365 It is included now. I'm keeping this open because I want to coerce someone to provide an example of its use. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=587011&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569057 ] Using .next() on file open in write mode writes junk to file
Bugs item #1569057, was opened at 2006-10-01 21:49
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569057&group_id=5470
Please note that this 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
Private: No
Submitted By: andrei kulakov (rainy)
>Assigned to: Brett Cannon (bcannon)
Summary: Using .next() on file open in write mode writes junk to file
Initial Comment:
When you open a file in write mode and use .next(), it
prints an error and writes many lines of junk to file.
I tested on windows and python 2.5:
>>> f = open('test', 'w')
>>> f.fileno()
4
>>> f.write('1\n')
>>> f.write('2\n3\n4\n')
>>> f.next()
Traceback (most recent call last):
File "", line 1, in
f.next()
IOError: [Errno 9] Bad file descriptor
>>> f.close()
>>> f = open('test')
>>> f.next()
'1\n'
>>> f.next()
'2\n'
>>> f.next()
'3\n'
>>> f.next()
'4\n'
>>> f.next()
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x
00\x00\x00\x00\x00\x
00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\x00\x00\
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00
...many more lines of junk...'
--
>Comment By: Brett Cannon (bcannon)
Date: 2007-03-20 17:44
Message:
Logged In: YES
user_id=357491
Originator: NO
I think the docs should just say switching is undefined and leave it at
that. Calling 'next' on a file open for writing just makes no sense
anyway. And who knows what the OS will do if you try to misuse a file
descriptor.
Other option is to raise an exception when 'next' is called on a file
opened for writing (TypeError?). I think that makes more sense.
Unfortunately having to check the mode every time you call 'next' might be
considered unacceptable. Anyone have an opinion?
Either way I will go with one of the two solutions.
--
Comment By: andrei kulakov (rainy)
Date: 2006-10-07 09:04
Message:
Logged In: YES
user_id=511010
I tried it on win2k sp4 running python 2.5 and right now
tried it on winXP running python 2.4 - same error. Also, at
least one user on python newsgroup tried it and got a
slightly different result: he did not get the error on
.next() but the junk was written to the file. I paste my
latest attempt right out of IDLE, without any modification
(my first paste was also straight from idle). Except that I
trim the junk characters, because there's more than a
screen of 'em.
IDLE 1.1.2
>>> f = open('test', 'w')
>>> f.write('1\n')
>>> f.next()
Traceback (most recent call last):
File "", line 1, in -toplevel-
f.next()
IOError: [Errno 9] Bad file descriptor
>>> f.close()
>>> f = open('test')
>>> f.next()
'1\n'
>>> f.next()
"\x95\x00\xc8\xe ..."
Please let me know if you need to know anything else...
--
Comment By: Skip Montanaro (montanaro)
Date: 2006-10-07 03:38
Message:
Logged In: YES
user_id=44345
Works for me. (Nearly current build from SVN.) I find it implausible that
your
explanation of failing to flush the file is the cause of the problem since
closing
the file will cause it to be flushed. You didn't open the file for "w+"
so there's no
opportunity to switch between writing and reading.
What platform are you using?
--
Comment By: andrei kulakov (rainy)
Date: 2006-10-03 18:23
Message:
Logged In: YES
user_id=511010
Python newsgroup folks said that this is normal because when
switching between write/read modes without doing flush()
first, result is undefined. There was a suggestion from
Terry Ready to add this to documentation on file methods:
"When switching from reading or writing (or vice versa),
call flush(), or
the result will be undefined."
thx, -andrei
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569057&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1682241 ] Problems with urllib2 read()
Bugs item #1682241, was opened at 2007-03-16 12:00 Message generated for change (Comment added) made by maenpaa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682241&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lucas Malor (lucas_malor) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with urllib2 read() Initial Comment: urllib2 objects opened with urlopen() does not have the method seek() as file objects. So reading only some bytes from opened urls is pratically forbidden. An example: I tried to open an url and check if it's a gzip file. If IOError is raised I read the file (to do this I applied the #1675951 patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1675951&group_id=5470&atid=305470 ) But after I tried to open the file as gzip, if it's not a gzip file the current position in the urllib object is on the second byte. So read() returns the data from the 3rd to the last byte. You can't check the header of the file before storing it on hd. Well, so what is urlopen() for? If I must store the file by url on hd and reload it, I can use urlretrieve() ... -- Comment By: Zacherates (maenpaa) Date: 2007-03-20 21:39 Message: Logged In: YES user_id=1421845 Originator: NO > I use the method you wrote, but this must be done manually, > and I don't know why. read() is a stream processing method, whereas seek() is a random access processing method. HTTP resources are in essence streams so they implement read() but not seek(). Trying to shoehorn a stream to act like a random access file has some rather important technical implications. For example: what happens when an HTTP resource is larger than available memory and we try to maintain a full featured seek() implementation? > so what is urlopen() for? Fetching a webpage or RSS feed and feeding it to a parser, for example. StringIO is a class that was designed to implement feature complete, random access, file-like object behavior that can be wrapped around a stream. StringIO can and should be used as an adapter for when you have a stream that you need random access to. This allows designers the freedom to simply implement a good read() implementation and let clients wrap the output in a StringIO if needed. If in your application you always want random access and you don't have to deal with large files: def my_urlopen(*args, **kwargs): return StringIO.StringIO(urllib2.urlopen(*args, **kwargs).read()) Python makes delegation trivially easy. In essence, urlfiles (the result of urllib2.urlopen()) and regular files (the result of open()) behave differently because they implement different interfaces. If you use the common interface (read), then you can treat them equally. If you use the specialized interface (seek, tell, etc.) you'll have trouble. The solution is wrap the general objects in a specialized object that implements the desired interface, StringIO. -- Comment By: Lucas Malor (lucas_malor) Date: 2007-03-20 04:59 Message: Logged In: YES user_id=1403274 Originator: YES > If you need to seek, you can wrap the file-like object in a > StringIO (which is what urllib would have to do internally > [...] ) I think it's really a bug, or at least a non-pythonic method. I use the method you wrote, but this must be done manually, and I don't know why. Actually without this "trick" you can't handle url and file objects together as they don't work in the same manner. I think it's not too complicated using the internal StringIO object in urllib class when I must seek() or use other file-like methods. > You can check the type of the response content before you try > to uncompress it via the Content-Encoding header of the > response It's not a generic solution (thanks anyway for suggested solutions :) ) -- Comment By: Zacherates (maenpaa) Date: 2007-03-19 22:43 Message: Logged In: YES user_id=1421845 Originator: NO I'd contend that this is not a bug: * If you need to seek, you can wrap the file-like object in a StringIO (which is what urllib would have to do internally, thus incurring the StringIO overhead for all clients, even those that don't need the functionality). * You can check the type of the response content before you try to uncompress it via the Content-Encoding header of the response. The meta-data is there for a reason. Check http://www.diveintopython.org/http_web_services/gzip_compression.html for a rather complete treatment of your use-case. -
[ python-Bugs-1684811 ] modindex.html builds incorrectly in Python 3
Bugs item #1684811, was opened at 2007-03-20 19:14 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684811&group_id=5470 Please note that this 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 3000 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: modindex.html builds incorrectly in Python 3 Initial Comment: Running "make distclean; make" in Python 3's Doc/ directory (as of r54467) leaves me with a content-less modindex.html. The header and footer are present, but there's no list of modules. The same steps on trunk/ (SVN HEAD) produce the expected module list. The mkmodindex step reports "0 index nodes". Watching the lines that mkmodindex:main() parses, none of them are related to modules (in the correct format or otherwise). I've attached a copy of the bad modindex.html that "make" generated. Also attached is a patch that allows Doc/tools/ to work with Python 3 (which it doesn't as of r54467). -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-20 22:00 Message: Logged In: YES user_id=1344176 Originator: YES I'm not sure what which change I've made in Doc/tools/ did it, but modindex.html now builds correctly after "make distclean". I'll check in the changes soon. Closing. -- Comment By: Collin Winter (collinwinter) Date: 2007-03-20 19:15 Message: Logged In: YES user_id=1344176 Originator: YES File Added: doc_tools.patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684811&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1684943 ] Keyword arguments to __init__() of a subclass of set
Bugs item #1684943, was opened at 2007-03-21 07: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=1684943&group_id=5470 Please note that this 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 Private: No Submitted By: Jørgen Frøjk Kjærsgaard (jfroejk) Assigned to: Nobody/Anonymous (nobody) Summary: Keyword arguments to __init__() of a subclass of set Initial Comment: Passing a keyword argument to a subclass of the built-in class "set" causes a TypeError in Python 2.4.2 and newer but not in 2.4.0. Example: class Test(set): def __init__(self, a=0): self.add(a) t = Test(a=0) In Python 2.4.0 it works as expected whereas in 2.4.2 and 2.4.4, it yields: Traceback (most recent call last): File "", line 1, in ? TypeError: set() does not take keyword arguments I don't pass a keyword argument to set.__init__() but to its subclass! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684943&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1684943 ] Keyword arguments to __init__() of a subclass of set
Bugs item #1684943, was opened at 2007-03-20 23:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684943&group_id=5470 Please note that this 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: Duplicate Priority: 5 Private: No Submitted By: Jørgen Frøjk Kjærsgaard (jfroejk) >Assigned to: Neal Norwitz (nnorwitz) Summary: Keyword arguments to __init__() of a subclass of set Initial Comment: Passing a keyword argument to a subclass of the built-in class "set" causes a TypeError in Python 2.4.2 and newer but not in 2.4.0. Example: class Test(set): def __init__(self, a=0): self.add(a) t = Test(a=0) In Python 2.4.0 it works as expected whereas in 2.4.2 and 2.4.4, it yields: Traceback (most recent call last): File "", line 1, in ? TypeError: set() does not take keyword arguments I don't pass a keyword argument to set.__init__() but to its subclass! -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-20 23:59 Message: Logged In: YES user_id=33168 Originator: NO 2.4 is no longer supported. This has been fixed in 2.5. I don't have the original bug report #. You can find the fix in SVN if you would like to build your own patched version. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684943&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1682749 ] next method assignment is ignored in new-style classes
Bugs item #1682749, was opened at 2007-03-17 08:06 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: Albert Weichselbraun (albert2611) Assigned to: Neal Norwitz (nnorwitz) Summary: next method assignment is ignored in new-style classes Initial Comment: in old-style classes the next method of an iterator-superclass can be "overwritten" using self.next = self.new_next_method when new-style classes are used the assignment is ignored and instead of new_next_method the next method of the superclass is called when the class is used as iterator (tested for python2.3-2.5 under debian/linux). - if the next() method is called directly, the assigned method is used (see attached code example). -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-21 00:02 Message: Logged In: YES user_id=33168 Originator: NO Yup, based on mail thread this behaviour seems correct. Unfortunately, I don't think it's properly documented or consistent either. :-( -- Comment By: Albert Weichselbraun (albert2611) Date: 2007-03-17 09:27 Message: Logged In: YES user_id=806170 Originator: YES i only experienced this behavior for the next method in iterator classes. overwriting methods with other names using an assignment works as expected. -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 08:52 Message: Logged In: YES user_id=849994 Originator: NO This is another incarnation of __methods__ being looked up on the type, not the instance, except that next() is not a __method__ yet. For new-style classes, this behavior is considered correct. Neal? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
