[ python-Bugs-1218234 ] inspect.getsource doesn't update when a module is reloaded
Bugs item #1218234, was opened at 2005-06-10 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=1218234&group_id=5470 Please note that this 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 Submitted By: Björn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getsource doesn't update when a module is reloaded Initial Comment: This is test.py: def foo(): print "Bla" And in an interactive session: >>> import inspect, test >>> test.foo() Bla >>> inspect.getsource(test.foo) 'def foo():\nprint "Bla"\n' Now I edit test.py to (without exiting the interactive session): def foo(): print "Oh no!" >>> reload(test) >>> test.foo() Oh no! >>> inspect.getsource(test.foo) 'def foo():\nprint "Bla"\n' inspect should output the new source. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218234&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-1218333 ] Create a fat build on darwin
Feature Requests item #1218333, was opened at 2005-06-10 18:34 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=1218333&group_id=5470 Please note that this 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: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: Create a fat build on darwin Initial Comment: Apple recently announced that they will switch to intel CPU's for their systems. They request that vendors build fat binaries for software. IMHO the python build process should be changed to make this easily possible. Areas that (might) need changing: * autoconf checks for CPU features (endianness, sizes of basic types). That won't work with cross-builds. A possible solution: create a pycpufeatures.h that hardcodes the information. * distutils might need to be taught about creating fat binaries. * It might be necessary to link to a specific SDK, this in turn might require changes in the autoconf machinery. NOTE: I intend to do some work on this in due time. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1218333&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1218234 ] inspect.getsource doesn't update when a module is reloaded
Bugs item #1218234, was opened at 2005-06-10 15:49 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218234&group_id=5470 Please note that this 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 Submitted By: Björn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getsource doesn't update when a module is reloaded Initial Comment: This is test.py: def foo(): print "Bla" And in an interactive session: >>> import inspect, test >>> test.foo() Bla >>> inspect.getsource(test.foo) 'def foo():\nprint "Bla"\n' Now I edit test.py to (without exiting the interactive session): def foo(): print "Oh no!" >>> reload(test) >>> test.foo() Oh no! >>> inspect.getsource(test.foo) 'def foo():\nprint "Bla"\n' inspect should output the new source. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-10 18:36 Message: Logged In: YES user_id=1188172 This is the fault of the linecache module which inspect uses. It caches the file contents and does not reload it accordingly. However, I assume it's pretty hard finding a good solution to this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218234&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-1185383 ] Make bisect.* functions accept an optional compare function
Feature Requests item #1185383, was opened at 2005-04-18 21:26 Message generated for change (Comment added) made by jonaskoelker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1185383&group_id=5470 Please note that this 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: Marcin Ciura (mciura) Assigned to: Nobody/Anonymous (nobody) Summary: Make bisect.* functions accept an optional compare function Initial Comment: The usability of bisect.bisect_right, bisect.bisect_left, bisect.insort_right and bisect.insort_left would increase if they accepted an optional less_than function to compare the keys. Here is my use case: I have a sorted list of reversed words and a parallel list of flags associated with these words (taken from ispell). The list of reversed words is the one searched; the flags are the result of a search. Issue #1: Now I cannot use simply a list of tuples (rev_word,flags) and a custom less_than function that compares only the first elements of two tuples. Issue #2: When a word is not found in the list, I'd like to make an educated guess as to its flags (this makes more sense in non-English languages, where e.g. infinitives have a special ending), using bisect_left and bisect_right: from bisect import * less_than = lambda x,y: x[:3] [...] but it could be a significant benefit for other functions that are expensive to compute (because repeated calls to bisect will access the lt function more than once). > Each subsequect call to bisect() would need to repeat those calls for a log(N) subset of the data. Which is exactly *why* I'm suggesting the key argument: to save those extra calls to the key function. Since that sounds counter-intuitive, let me explain: one sorts (origkey(item), item) pairs, the bisects with key=itemgetter(0), not calling the expensive origkey. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-03 03:25 Message: Logged In: YES user_id=80475 Overall, I'm -1 on this RFE. The comparison to nsmallest() and nlargest() is inaccurate. They run start-to-finish in one function call. The other heapq methods do not use key functions because they have to leave the original data structure unmolested between calls; hence, there is no ability to limit the key function calls to one per record. Likewise, with this request, the key function calls get wasted. The sort() method calls key() for every record and tosses the result afterwards. Each subsequect call to bisect() would need to repeat those calls for a log(N) subset of the data. Hence, accepting this request would create an API that encourages a wasteful design. -- Comment By: Jonas Kölker (jonaskoelker) Date: 2005-04-28 22:13 Message: Logged In: YES user_id=1153395 In a similar vein, I'd like to see that a `key' keyword argument was added to bisect.* (and perhaps `reversed' too)--it's really annoying to sort something by (not __lt__) and not be able to bsearch it. It got added to min/max and heapq.n(smallest|largest) in 2.5 fwiw ;) -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-18 22:09 Message: Logged In: YES user_id=80475 A few thoughts: * If bisect provided an optional lt argument, it would still not be thread-safe. The code for the lt function can call arbitrary Python code that runs through the eval-loop and is hence subject to a thread-switch. * An advantage of the class wrapper approach is that the prefix function gets computed just once per word. This is not a big deal for the specific case of [:3], but it could be a significant benefit for other functions that are expensive to compute (because repeated calls to bisect will access the lt function more than once). * My own approach to the particular use case would be to map prefixes to a list of revwords or (revword, flag) pairs: d = dict(abb=['abbc'], abc=['abcaa', 'abcdd', 'abcss'], abd=['abdf']) This gives O(1) lookup time and limits the calls to the prefix function to once per word. Will leave this request open as it may yet be a good idea. My concern is that it will clutter the code and the API for only a small benefit. Also, I'm looking at a more general purpose solution that would make this feature request moot. This idea is to create a fast comparison decorator class used like this: dwordlist = map(ComparisonDecorator(lambda x: x[:3]), wordlist) lp = bisect_left(dwordlist, given_rev_word) rp = bisect_right(dwordlist, given_rev_word) -- You can respond by visiting: https://sourceforge.net/tracker/?func=
[ python-Feature Requests-1185383 ] Make bisect.* functions accept an optional compare function
Feature Requests item #1185383, was opened at 2005-04-18 14:26 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1185383&group_id=5470 Please note that this 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: Rejected Priority: 5 Submitted By: Marcin Ciura (mciura) Assigned to: Nobody/Anonymous (nobody) Summary: Make bisect.* functions accept an optional compare function Initial Comment: The usability of bisect.bisect_right, bisect.bisect_left, bisect.insort_right and bisect.insort_left would increase if they accepted an optional less_than function to compare the keys. Here is my use case: I have a sorted list of reversed words and a parallel list of flags associated with these words (taken from ispell). The list of reversed words is the one searched; the flags are the result of a search. Issue #1: Now I cannot use simply a list of tuples (rev_word,flags) and a custom less_than function that compares only the first elements of two tuples. Issue #2: When a word is not found in the list, I'd like to make an educated guess as to its flags (this makes more sense in non-English languages, where e.g. infinitives have a special ending), using bisect_left and bisect_right: from bisect import * less_than = lambda x,y: x[:3]Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-10 21:26 Message: Logged In: YES user_id=80475 The whole purpose of the key= argument was to avoid having to build (key, record) tuples. If those are going to be built anyway, then there is little point to using key=. Closing this because: 1) the original use case was better addressed through other methods 2) key= for bisect does not provide the same benefits as it does for other functions. 3) the most recent proposed use is far afield from what key= is supposed to do 4) I think it is bad design and would encourage misguided approaches. -- Comment By: Jonas Kölker (jonaskoelker) Date: 2005-06-10 18:44 Message: Logged In: YES user_id=1153395 > [...] but it could be a significant benefit for other functions that are expensive to compute (because repeated calls to bisect will access the lt function more than once). > Each subsequect call to bisect() would need to repeat those calls for a log(N) subset of the data. Which is exactly *why* I'm suggesting the key argument: to save those extra calls to the key function. Since that sounds counter-intuitive, let me explain: one sorts (origkey(item), item) pairs, the bisects with key=itemgetter(0), not calling the expensive origkey. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 20:25 Message: Logged In: YES user_id=80475 Overall, I'm -1 on this RFE. The comparison to nsmallest() and nlargest() is inaccurate. They run start-to-finish in one function call. The other heapq methods do not use key functions because they have to leave the original data structure unmolested between calls; hence, there is no ability to limit the key function calls to one per record. Likewise, with this request, the key function calls get wasted. The sort() method calls key() for every record and tosses the result afterwards. Each subsequect call to bisect() would need to repeat those calls for a log(N) subset of the data. Hence, accepting this request would create an API that encourages a wasteful design. -- Comment By: Jonas Kölker (jonaskoelker) Date: 2005-04-28 15:13 Message: Logged In: YES user_id=1153395 In a similar vein, I'd like to see that a `key' keyword argument was added to bisect.* (and perhaps `reversed' too)--it's really annoying to sort something by (not __lt__) and not be able to bsearch it. It got added to min/max and heapq.n(smallest|largest) in 2.5 fwiw ;) -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-18 15:09 Message: Logged In: YES user_id=80475 A few thoughts: * If bisect provided an optional lt argument, it would still not be thread-safe. The code for the lt function can call arbitrary Python code that runs through the eval-loop and is hence subject to a thread-switch. * An advantage of the class wrapper approach is that the prefix function gets computed just once per word. This is not a big deal for the specific case of [:3], but it could be a significant benefit for other functions that are expensive to compute (because repeated calls to bisect will access the lt function more than once). * My own approach to the particular use case would be to map prefixes to a list of revwords or (revword, fl
[ python-Bugs-1218081 ] email.Utils.py: "'" in RFC2231 header
Bugs item #1218081, was opened at 2005-06-10 10: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=1218081&group_id=5470
Please note that this 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: Tokio Kikuchi (tkikuchi)
Assigned to: Nobody/Anonymous (nobody)
Summary: email.Utils.py: "'" in RFC2231 header
Initial Comment:
A header like this one can cause ValueError in
attempting to decode the RFC2231 format:
Content-Disposition: inline;
filename*0="Today's Headlines- C.I.A. Is
Reviewing Its Security Policy
for R"; filename*1="ecruiting Translators.jpg"
Note that there is a ' in the filename. MUA should
have escaped the ' by %27 but Python email library
should be robust for such a violation.
Here is the traceback:
>>> print p[4]['content-disposition']
inline;
filename*0="Today's Headlines- C.I.A. Is
Reviewing Its Security Policy
for R"; filename*1="ecruiting Translators.jpg"
>>> p[4].get_filename()
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.4/email/Message.py",
line 707, in get_filename
filename = self.get_param('filename', missing,
'content-disposition')
File "/usr/local/lib/python2.4/email/Message.py",
line 590, in get_param
for k, v in self._get_params_preserve(failobj, header):
File "/usr/local/lib/python2.4/email/Message.py",
line 537, in _get_params_pre
serve
params = Utils.decode_params(params)
File "/usr/local/lib/python2.4/email/Utils.py", line
275, in decode_params
charset, language, value =
decode_rfc2231(EMPTYSTRING.join(value))
File "/usr/local/lib/python2.4/email/Utils.py", line
222, in decode_rfc2231
charset, language, s = parts
ValueError: need more than 2 values to unpack
>>>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218081&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1218081 ] email.Utils.py: "'" in RFC2231 header
Bugs item #1218081, was opened at 2005-06-10 10:07
Message generated for change (Settings changed) made by tkikuchi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218081&group_id=5470
Please note that this 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: Tokio Kikuchi (tkikuchi)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Utils.py: "'" in RFC2231 header
Initial Comment:
A header like this one can cause ValueError in
attempting to decode the RFC2231 format:
Content-Disposition: inline;
filename*0="Today's Headlines- C.I.A. Is
Reviewing Its Security Policy
for R"; filename*1="ecruiting Translators.jpg"
Note that there is a ' in the filename. MUA should
have escaped the ' by %27 but Python email library
should be robust for such a violation.
Here is the traceback:
>>> print p[4]['content-disposition']
inline;
filename*0="Today's Headlines- C.I.A. Is
Reviewing Its Security Policy
for R"; filename*1="ecruiting Translators.jpg"
>>> p[4].get_filename()
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.4/email/Message.py",
line 707, in get_filename
filename = self.get_param('filename', missing,
'content-disposition')
File "/usr/local/lib/python2.4/email/Message.py",
line 590, in get_param
for k, v in self._get_params_preserve(failobj, header):
File "/usr/local/lib/python2.4/email/Message.py",
line 537, in _get_params_pre
serve
params = Utils.decode_params(params)
File "/usr/local/lib/python2.4/email/Utils.py", line
275, in decode_params
charset, language, value =
decode_rfc2231(EMPTYSTRING.join(value))
File "/usr/local/lib/python2.4/email/Utils.py", line
222, in decode_rfc2231
charset, language, s = parts
ValueError: need more than 2 values to unpack
>>>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1218081&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1215928 ] Large tarfiles cause overflow
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: Open Resolution: None Priority: 5 Submitted By: Tom Emerson (tree) Assigned to: Raymond Hettinger (rhettinger) 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-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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
