[ python-Feature Requests-1322308 ] itemgetter built-in?
Feature Requests item #1322308, was opened at 2005-10-10 04:56
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1322308&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: capnSTABN (capnstabn)
Assigned to: Nobody/Anonymous (nobody)
Summary: itemgetter built-in?
Initial Comment:
uhm... operator.itemgetter() is useful and all, but fairly
retarded looking for how simple it is
basically what i am wrestling with at the moment is
doing some regular expressions without completely
ganking the crap out of the code to make it work, since
every freakin thing in re returns None all over the bloody
place like regular expressions were hitting a ragging
pinata with a chainsaw
after a LOT of muckymuck, basically six hours straight,
the simplest non-conditional form i could come up with
was this:
http://42.vg/81691";
target="_new">http://42.vg/81691
http://42.vg/81691
any comments would be leet!
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-11-14 07:19
Message:
Logged In: YES
user_id=80475
The use case is common enough to warrant further
exploration. Essentially what is being requested is a
straight-forward way to get a group dictionary that only
includes matching groups.
Two approaches come to mind.
1. Add a module constant, EXCLUDE, that when used as the
default value causes non-matching groups to be excluded from
the group dictionary:
d=mo.groupdict(re.EXCLUDE)
2. Create a new flag, N or NODEFAULT or (?N), indicating
that match objects should only include matching groups and
not create default entries for non-matches:
d=match('(?\w+)|(?\d+)', s, NODEFAULT).groupdict()
FWIW, am not sympathetic to the OP's code fragment not being
explicit. That is what happens when trying too hard to
avoid using an if-statement. The fragment is much clearer
without filtering:
for type, string_ in mo.groupdict().iteritems():
if string_ is not None:
. . .
--
Comment By: capnSTABN (capnstabn)
Date: 2005-10-11 04:33
Message:
Logged In: YES
user_id=1126596
ok to be more specific, as maybe that will help, line 17 in the
code:
for type, string_ in (filter(itemgetter(1), match.groupdict
().iteritems())):
is about as implicit as pulling a tooth to remove a strand of
celery
the problem is that when using a single expansive recursive
regular expression (which can translate an entire page of
HTML like in any WikiWiki system in microseconds) that the
amount of recursive calls because of all of the Nones flying
around gets ludicrous
a bit of a glimpse of a considerably more complex example:
http://generic-host.us/~kevin/display_renderer.png
please bear in mind that example is from 1999 or so
--
Comment By: capnSTABN (capnstabn)
Date: 2005-10-11 04:17
Message:
Logged In: YES
user_id=1126596
my request for enhancement is either a built-in version of
operation.itemgetter() or an alteration of the behavior of re
matches, i'm assuming the matter is up for debate so i wasn't
being specific.
this issue has nothing to do with showing code and i find your
followup to be completely off topic!
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-10-10 11:57
Message:
Logged In: YES
user_id=1188172
Please tell us what your request for enhancement is or I'm
going to close this as Invalid.
Sorry I'm not showing more respect for your writing
abilities :-), but if you want to show code around, do it on
comp.lang.python please.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1322308&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-1351692 ] Switch to make pprint.pprint display ints and longs in hex
Feature Requests item #1351692, was opened at 2005-11-08 16:29 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this 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: Mark Hirota (markhirota) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x1,0x10010)) # and this: [0x1L, 0x10001L, 0x10002L, 0x10003L, 0x10004L, 0x10005L, 0x10006L, 0x10007L, 0x10008L, 0x10009L, 0x1000AL, 0x1000BL, 0x1000CL, 0x1000DL, 0x1000EL, 0x1000FL] >>> Thanks, --MH -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-14 06:19 Message: Logged In: YES user_id=80475 Fred, any thoughts on the vision for your module? IMHO, pprinting containers with ints represented in hex is not an especially compelling motivation for a total rewrite. OTOH, it would be nice if the module were easily extensible.. -- Comment By: Walter Dörwald (doerwalter) Date: 2005-11-14 04:54 Message: Logged In: YES user_id=89016 I find pprint.py hard to understand as it is. I've been staring at the code for several days now and the difference between PrettyPrinter._format(), PrettyPrinter.format(), PrettyPrinter._repr() and _safe_repr() is still not entirely clear to me. Using a subclass of int only makes sense, if it's your own data structure that you're outputting. If you get it from somewhere else, traversing it and replacing every int with an Int just for output really isn't an option. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-12 15:02 Message: Logged In: YES user_id=80475 IMO, such a rewrite would expose too many of pprint's internals and make the module harder to use/understand/maintain. Wouldn't it be better to stick with the usual idiom for controlling the repr() formatting of specific types by using a class wrapper: >>> from pprint import pprint >>> class Int(int): def __repr__(self): return hex(self) >>> pprint([Int(x) for x in range(0x1000,0x1010)]) [0x1000, 0x1001, 0x1002, 0x1003, 0x1004, 0x1005, 0x1006, 0x1007, 0x1008, 0x1009, 0x100a, 0x100b, 0x100c, 0x100d, 0x100e, 0x100f] -- Comment By: Walter Dörwald (doerwalter) Date: 2005-11-12 14:29 Message: Logged In: YES user_id=89016 I think it's more of a limitation. I seems to me the main focus in implementing pprint was speed not extensibility. The code uses every trick in the book (e.g. turning globals and builtins into locals, using bound methods etc.). I think it was never ment to do anything other than what repr() does, but with better formatting. However IMHO making pprint extensible would be a worthwile project. -- Comment By: Mark Hirota (markhirota) Date: 2005-11-11 12:47 Message: Logged In: YES user_id=1375527 Is this bypassing considered a limitation or a bug? I am, however, able to workaround the issue by setting the width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that instead of: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] I get instead: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] ...which is OK for my uses. Thanks! -- Comment By: Walter Dörwald (doerwalter) Date: 2005-11-10 17:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't wor
[ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex
Feature Requests item #1351692, was opened at 2005-11-08 13:29 Message generated for change (Comment added) made by markhirota You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this 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: Mark Hirota (markhirota) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x1,0x10010)) # and this: [0x1L, 0x10001L, 0x10002L, 0x10003L, 0x10004L, 0x10005L, 0x10006L, 0x10007L, 0x10008L, 0x10009L, 0x1000AL, 0x1000BL, 0x1000CL, 0x1000DL, 0x1000EL, 0x1000FL] >>> Thanks, --MH -- >Comment By: Mark Hirota (markhirota) Date: 2005-11-14 09:04 Message: Logged In: YES user_id=1375527 Sorry, but maybe I could just interject here. Walter's sub- classing example works fine, except for the fact that if the string is short enough, it gets handled slightly differently and the format() override gets bypassed. I worked around this by shortening the width, but I've found that this screws with a lot of the nice formatting of other structures, and so basically creates a new set of problems. If the "format() bypass" limitation can be removed, I think it would allow for more reliable extensibility by subclassing PrettyPrinter. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-14 03:19 Message: Logged In: YES user_id=80475 Fred, any thoughts on the vision for your module? IMHO, pprinting containers with ints represented in hex is not an especially compelling motivation for a total rewrite. OTOH, it would be nice if the module were easily extensible.. -- Comment By: Walter Dörwald (doerwalter) Date: 2005-11-14 01:54 Message: Logged In: YES user_id=89016 I find pprint.py hard to understand as it is. I've been staring at the code for several days now and the difference between PrettyPrinter._format(), PrettyPrinter.format(), PrettyPrinter._repr() and _safe_repr() is still not entirely clear to me. Using a subclass of int only makes sense, if it's your own data structure that you're outputting. If you get it from somewhere else, traversing it and replacing every int with an Int just for output really isn't an option. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-12 12:02 Message: Logged In: YES user_id=80475 IMO, such a rewrite would expose too many of pprint's internals and make the module harder to use/understand/maintain. Wouldn't it be better to stick with the usual idiom for controlling the repr() formatting of specific types by using a class wrapper: >>> from pprint import pprint >>> class Int(int): def __repr__(self): return hex(self) >>> pprint([Int(x) for x in range(0x1000,0x1010)]) [0x1000, 0x1001, 0x1002, 0x1003, 0x1004, 0x1005, 0x1006, 0x1007, 0x1008, 0x1009, 0x100a, 0x100b, 0x100c, 0x100d, 0x100e, 0x100f] -- Comment By: Walter Dörwald (doerwalter) Date: 2005-11-12 11:29 Message: Logged In: YES user_id=89016 I think it's more of a limitation. I seems to me the main focus in implementing pprint was speed not extensibility. The code uses every trick in the book (e.g. turning globals and builtins into locals, using bound methods etc.). I think it was never ment to do anything other than what repr() does, but with better formatting. However IMHO making pprint extensible would be a worthwile project. -- Comment By: Mark Hirota (markhirota) Date: 2005-11-11 09:47 Message: Logged In: YES user_id=1375527 Is this bypassing considered a limitation or a bug? I am, however, able to workaround the issue by setting the width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that instead of: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] I get instead: >>> mpp.pprint(range(10)
[ python-Bugs-1356720 ] Ctrl+C for copy does not work when caps-lock is on
Bugs item #1356720, was opened at 2005-11-14 12:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1356720&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lenny Domnitser (ldrhcp) Assigned to: Nobody/Anonymous (nobody) Summary: Ctrl+C for copy does not work when caps-lock is on Initial Comment: I only tested this on Windows/Python 2.4/Idle 1.1.2. Other shortcuts (Ctrl+V, Ctrl+X, etc.) work just fine, but Ctrl+C requires a lower case letter. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1356720&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-1351692 ] Switch to make pprint.pprint display ints and longs in hex
Feature Requests item #1351692, was opened at 2005-11-08 22:29 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this 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: Mark Hirota (markhirota) Assigned to: Nobody/Anonymous (nobody) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x1,0x10010)) # and this: [0x1L, 0x10001L, 0x10002L, 0x10003L, 0x10004L, 0x10005L, 0x10006L, 0x10007L, 0x10008L, 0x10009L, 0x1000AL, 0x1000BL, 0x1000CL, 0x1000DL, 0x1000EL, 0x1000FL] >>> Thanks, --MH -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-11-14 10:54 Message: Logged In: YES user_id=89016 I find pprint.py hard to understand as it is. I've been staring at the code for several days now and the difference between PrettyPrinter._format(), PrettyPrinter.format(), PrettyPrinter._repr() and _safe_repr() is still not entirely clear to me. Using a subclass of int only makes sense, if it's your own data structure that you're outputting. If you get it from somewhere else, traversing it and replacing every int with an Int just for output really isn't an option. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-12 21:02 Message: Logged In: YES user_id=80475 IMO, such a rewrite would expose too many of pprint's internals and make the module harder to use/understand/maintain. Wouldn't it be better to stick with the usual idiom for controlling the repr() formatting of specific types by using a class wrapper: >>> from pprint import pprint >>> class Int(int): def __repr__(self): return hex(self) >>> pprint([Int(x) for x in range(0x1000,0x1010)]) [0x1000, 0x1001, 0x1002, 0x1003, 0x1004, 0x1005, 0x1006, 0x1007, 0x1008, 0x1009, 0x100a, 0x100b, 0x100c, 0x100d, 0x100e, 0x100f] -- Comment By: Walter Dörwald (doerwalter) Date: 2005-11-12 20:29 Message: Logged In: YES user_id=89016 I think it's more of a limitation. I seems to me the main focus in implementing pprint was speed not extensibility. The code uses every trick in the book (e.g. turning globals and builtins into locals, using bound methods etc.). I think it was never ment to do anything other than what repr() does, but with better formatting. However IMHO making pprint extensible would be a worthwile project. -- Comment By: Mark Hirota (markhirota) Date: 2005-11-11 18:47 Message: Logged In: YES user_id=1375527 Is this bypassing considered a limitation or a bug? I am, however, able to workaround the issue by setting the width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that instead of: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] I get instead: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] ...which is OK for my uses. Thanks! -- Comment By: Walter Dörwald (doerwalter) Date: 2005-11-10 23:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't work reliable though: When the string is short enough, format() seems to be bypassed and repr() is called directly. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 22:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. -- You can respond by
[ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex
Feature Requests item #1351692, was opened at 2005-11-08 13:29 Message generated for change (Comment added) made by markhirota You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this 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: Mark Hirota (markhirota) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x1,0x10010)) # and this: [0x1L, 0x10001L, 0x10002L, 0x10003L, 0x10004L, 0x10005L, 0x10006L, 0x10007L, 0x10008L, 0x10009L, 0x1000AL, 0x1000BL, 0x1000CL, 0x1000DL, 0x1000EL, 0x1000FL] >>> Thanks, --MH -- >Comment By: Mark Hirota (markhirota) Date: 2005-11-14 10:33 Message: Logged In: YES user_id=1375527 Did some digging into the code and found that the "if sepLines:" condition in the PrettyPrinter._format() method was the source of the limitation. I've attached a modified version of pprint.py where the "if sepLines" is more embedded. It gives the following results: >>> import pprintmod >>> class MyPrettyPrinter(pprintmod.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprintmod.PrettyPrinter.format( self, object, context, maxlevels, level) >>> mpp = MyPrettyPrinter() >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> mpp.pprint(range(0x1000,0x1010)) [0x1000, 0x1001, 0x1002, 0x1003, 0x1004, 0x1005, 0x1006, 0x1007, 0x1008, 0x1009, 0x100a, 0x100b, 0x100c, 0x100d, 0x100e, 0x100f] >>> Would this be an acceptable change? Thanks, -- Comment By: Mark Hirota (markhirota) Date: 2005-11-14 09:04 Message: Logged In: YES user_id=1375527 Sorry, but maybe I could just interject here. Walter's sub- classing example works fine, except for the fact that if the string is short enough, it gets handled slightly differently and the format() override gets bypassed. I worked around this by shortening the width, but I've found that this screws with a lot of the nice formatting of other structures, and so basically creates a new set of problems. If the "format() bypass" limitation can be removed, I think it would allow for more reliable extensibility by subclassing PrettyPrinter. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-14 03:19 Message: Logged In: YES user_id=80475 Fred, any thoughts on the vision for your module? IMHO, pprinting containers with ints represented in hex is not an especially compelling motivation for a total rewrite. OTOH, it would be nice if the module were easily extensible.. -- Comment By: Walter Dörwald (doerwalter) Date: 2005-11-14 01:54 Message: Logged In: YES user_id=89016 I find pprint.py hard to understand as it is. I've been staring at the code for several days now and the difference between PrettyPrinter._format(), PrettyPrinter.format(), PrettyPrinter._repr() and _safe_repr() is still not entirely clear to me. Using a subclass of int only makes sense, if it's your own data structure that you're outputting. If you get it from somewhere else, traversing it and replacing every int with an Int just for output really isn't an option. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-12 12:02 Message: Logged In: YES user_id=80475 IMO, such a rewrite would expose too many of pprint's internals and make the module harder to use/understand/maintain. Wouldn't it be better to stick with the usual idiom for controlling the repr() formatting of specific types by using a class wrapper: >>> from pprint import pprint >>> class Int(int): def __repr__(self): return hex(self) >>> pprint([Int(x) for x in range(0x1000,0x100
[ python-Bugs-1356720 ] Ctrl+C for copy does not work when caps-lock is on
Bugs item #1356720, was opened at 2005-11-14 19:20 Message generated for change (Comment added) made by noamr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1356720&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lenny Domnitser (ldrhcp) Assigned to: Nobody/Anonymous (nobody) Summary: Ctrl+C for copy does not work when caps-lock is on Initial Comment: I only tested this on Windows/Python 2.4/Idle 1.1.2. Other shortcuts (Ctrl+V, Ctrl+X, etc.) work just fine, but Ctrl+C requires a lower case letter. -- Comment By: Noam Raphael (noamr) Date: 2005-11-14 22:28 Message: Logged In: YES user_id=679426 I didn't reproduce it, but it must be because the key binding for interrupt-execution is set to " " only in the "IDLE Classic - Windows" keybinding set, and not in the Mac and Unix variants, where it's only "". I don't find the place to attach a file (new sourceforge style), so here it is: Index: config-keys.def === --- config-keys.def (revision 41443) +++ config-keys.def (working copy) @@ -70,7 +70,7 @@ end-of-file= history-next= history-previous= -interrupt-execution= +interrupt-execution= view-restart= restart-shell= open-class-browser= @@ -123,7 +123,7 @@ python-context-help= history-next= history-previous= -interrupt-execution= +interrupt-execution= view-restart= restart-shell= open-class-browser= Noam -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1356720&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1353504 ] Python drops core when stdin is bogus
Bugs item #1353504, was opened at 2005-11-10 16:16 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Neal Norwitz (nnorwitz) Summary: Python drops core when stdin is bogus Initial Comment: Someone here at work had the bright idea to execute a Python script from a Solaris 10 ~/.dtprofile file. Apparently, at the time that script is run stdin is bogus. Python core dumps with this gdb backtrace: #0 0x0807d290 in PyDict_SetItem (op=0x815b79c, key=0x8163f20, value=0x0) at ../Objects/dictobject.c:549 #1 0x0807e0f7 in PyDict_SetItemString (v=0x815b79c, key=0x8118df2 "stdin", item=0x0) at ../Objects/dictobject.c:1988 #2 0x080e0d03 in _PySys_Init () at ../Python/sysmodule.c:977 #3 0x080ddfdb in Py_InitializeEx (install_sigs=1) at ../Python/pythonrun.c:190 #4 0x080dfa89 in Py_Initialize () at ../Python/pythonrun.c:283 #5 0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at ../Modules/main.c:418 #6 0x0805ca13 in main (argc=3, argv=0x8047c08) at ../Modules/python.c:23 (This is from 2.4.2, but it also happens in 2.3.4.) Looking at the code in _PySys_Init it calls sysin = PyFile_FromFile(stdin, "", "r", NULL); which returns NULL. In PyFile_FromFile it creates a new PyFileObject, then initializes it by calling a static function, fill_file_fields. This apparently fails, causing a NULL pointer return. Back in _PySys_Init it checks PyErr_Occurred, but fill_file_fields never raised an except. The NULL pointer is passed to PyDict_SetItemString and havoc ensues. I haven't checked CVS, but 2.4 (and probably 2.3) should be fixed. I suggest raising an IOError in fill_file_fields instead of just setting f to NULL and returning it. -- >Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 16:01 Message: Logged In: YES user_id=44345 Well, I built from CVS^H^H^HSubversion HEAD at work and tried again. Still got a core dump, but that was a side-effect of calling Py_FatalError. Is that the intended behavior? I guess with a bogus stderr that makes sense, but if stderr happened to be valid at this point, I'd rather have it raise something more meaningful for the user, like SystemError. -- Comment By: Skip Montanaro (montanaro) Date: 2005-11-12 07:18 Message: Logged In: YES user_id=44345 Thanks Neal. I'll check it out at work next week. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-11 01:24 Message: Logged In: YES user_id=33168 This should be fixed in 2.4.3 and CVS (2.3.5 is probably affected too). I remember dealing with directories specifically. Checkout the current sysmodule.c. Here's the checkin: r39652 | nnorwitz | 2005-10-02 18:03:46 -0700 (Sun, 02 Oct 2005) | 5 lines SF bug #887946. Let me know if this bug is different and the patch doesn't solve the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1353504 ] Python drops core when stdin is bogus
Bugs item #1353504, was opened at 2005-11-10 14:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Neal Norwitz (nnorwitz) Summary: Python drops core when stdin is bogus Initial Comment: Someone here at work had the bright idea to execute a Python script from a Solaris 10 ~/.dtprofile file. Apparently, at the time that script is run stdin is bogus. Python core dumps with this gdb backtrace: #0 0x0807d290 in PyDict_SetItem (op=0x815b79c, key=0x8163f20, value=0x0) at ../Objects/dictobject.c:549 #1 0x0807e0f7 in PyDict_SetItemString (v=0x815b79c, key=0x8118df2 "stdin", item=0x0) at ../Objects/dictobject.c:1988 #2 0x080e0d03 in _PySys_Init () at ../Python/sysmodule.c:977 #3 0x080ddfdb in Py_InitializeEx (install_sigs=1) at ../Python/pythonrun.c:190 #4 0x080dfa89 in Py_Initialize () at ../Python/pythonrun.c:283 #5 0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at ../Modules/main.c:418 #6 0x0805ca13 in main (argc=3, argv=0x8047c08) at ../Modules/python.c:23 (This is from 2.4.2, but it also happens in 2.3.4.) Looking at the code in _PySys_Init it calls sysin = PyFile_FromFile(stdin, "", "r", NULL); which returns NULL. In PyFile_FromFile it creates a new PyFileObject, then initializes it by calling a static function, fill_file_fields. This apparently fails, causing a NULL pointer return. Back in _PySys_Init it checks PyErr_Occurred, but fill_file_fields never raised an except. The NULL pointer is passed to PyDict_SetItemString and havoc ensues. I haven't checked CVS, but 2.4 (and probably 2.3) should be fixed. I suggest raising an IOError in fill_file_fields instead of just setting f to NULL and returning it. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 14:08 Message: Logged In: YES user_id=33168 Did you mistype and still mean stdin or are we talking about stderr? IIRC, calling Py_FatalError() was what I intended if stdin is bogus. I don't know what else to do. If you can think of scenarios where we could improve the behaviour, I think that's fine to do. I suppose you could set stdin to None, but I'm not sure what that would do or if it would improve anything. -- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 14:01 Message: Logged In: YES user_id=44345 Well, I built from CVS^H^H^HSubversion HEAD at work and tried again. Still got a core dump, but that was a side-effect of calling Py_FatalError. Is that the intended behavior? I guess with a bogus stderr that makes sense, but if stderr happened to be valid at this point, I'd rather have it raise something more meaningful for the user, like SystemError. -- Comment By: Skip Montanaro (montanaro) Date: 2005-11-12 05:18 Message: Logged In: YES user_id=44345 Thanks Neal. I'll check it out at work next week. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-10 23:24 Message: Logged In: YES user_id=33168 This should be fixed in 2.4.3 and CVS (2.3.5 is probably affected too). I remember dealing with directories specifically. Checkout the current sysmodule.c. Here's the checkin: r39652 | nnorwitz | 2005-10-02 18:03:46 -0700 (Sun, 02 Oct 2005) | 5 lines SF bug #887946. Let me know if this bug is different and the patch doesn't solve the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&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-1080727 ] Add encoding to DocFileSuite
Feature Requests item #1080727, was opened at 2004-12-07 16:47 Message generated for change (Comment added) made by dcjim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Tillenius (bjoti) >Assigned to: Jim Fulton (dcjim) Summary: Add encoding to DocFileSuite Initial Comment: If one writes doctests within documentation strings of classes and functions, it's possible to use non-ASCII characters since one can specify the encoding used in the source file. But if one wants to combine the documentation and testing, by writing a text file, and thus use DocFileSuite, it's not possible to use non-ASCII characters in the tests. This is because there's no way of specifying which encoding the text file uses. Instead one has to \-quote all non-ASCII characters, and that makes the tests harder to read IMHO. -- >Comment By: Jim Fulton (dcjim) Date: 2005-11-14 22:50 Message: Logged In: YES user_id=73023 The patch looks good to me. I haven't looked at the tests, but I assume that they are good too. I will look at them. :) I'm also going to add PEP 263-style encoding specification. Thanks! -- Comment By: Bjorn Tillenius (bjoti) Date: 2005-09-13 20:12 Message: Logged In: YES user_id=1032069 Attaching new version of the patch that will apply cleanly against latest CVS -- Comment By: Tim Peters (tim_one) Date: 2005-09-13 18:59 Message: Logged In: YES user_id=31435 Ed, can you make time to review this patch? If not, please unassign it again. -- Comment By: Bjorn Tillenius (bjoti) Date: 2004-12-18 18:05 Message: Logged In: YES user_id=1032069 Uploaded new patch, which adds the possibility to specify an encoding to testfile as well, since I assume this is desirable. -- Comment By: Bjorn Tillenius (bjoti) Date: 2004-12-18 14:08 Message: Logged In: YES user_id=1032069 Added patch for Tim to review. -- Comment By: Tim Peters (tim_one) Date: 2004-12-15 03:09 Message: Logged In: YES user_id=31435 Unassigned myself -- can't make time to work on it. I'll be happy to review a patch (code/tests/docs) if one appears. I approve of the idea . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1353504 ] Python drops core when stdin is bogus
Bugs item #1353504, was opened at 2005-11-10 16:16 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Neal Norwitz (nnorwitz) Summary: Python drops core when stdin is bogus Initial Comment: Someone here at work had the bright idea to execute a Python script from a Solaris 10 ~/.dtprofile file. Apparently, at the time that script is run stdin is bogus. Python core dumps with this gdb backtrace: #0 0x0807d290 in PyDict_SetItem (op=0x815b79c, key=0x8163f20, value=0x0) at ../Objects/dictobject.c:549 #1 0x0807e0f7 in PyDict_SetItemString (v=0x815b79c, key=0x8118df2 "stdin", item=0x0) at ../Objects/dictobject.c:1988 #2 0x080e0d03 in _PySys_Init () at ../Python/sysmodule.c:977 #3 0x080ddfdb in Py_InitializeEx (install_sigs=1) at ../Python/pythonrun.c:190 #4 0x080dfa89 in Py_Initialize () at ../Python/pythonrun.c:283 #5 0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at ../Modules/main.c:418 #6 0x0805ca13 in main (argc=3, argv=0x8047c08) at ../Modules/python.c:23 (This is from 2.4.2, but it also happens in 2.3.4.) Looking at the code in _PySys_Init it calls sysin = PyFile_FromFile(stdin, "", "r", NULL); which returns NULL. In PyFile_FromFile it creates a new PyFileObject, then initializes it by calling a static function, fill_file_fields. This apparently fails, causing a NULL pointer return. Back in _PySys_Init it checks PyErr_Occurred, but fill_file_fields never raised an except. The NULL pointer is passed to PyDict_SetItemString and havoc ensues. I haven't checked CVS, but 2.4 (and probably 2.3) should be fixed. I suggest raising an IOError in fill_file_fields instead of just setting f to NULL and returning it. -- >Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 17:57 Message: Logged In: YES user_id=44345 No, we're still discussing stdin. My only point is that what you do might be predicated on whether or not you think you can communicate with the user on stderr. My thought was that if stderr is valid you can raise an exception that prints a traceback. If not, Py_FatalError is your only recourse. Your code checks for the directori-ness of stdin as the first thing, then bails if it is. If it checked to see if stderr was valid first, it could decide to raise SystemError instead of calling Py_FatalError. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 16:08 Message: Logged In: YES user_id=33168 Did you mistype and still mean stdin or are we talking about stderr? IIRC, calling Py_FatalError() was what I intended if stdin is bogus. I don't know what else to do. If you can think of scenarios where we could improve the behaviour, I think that's fine to do. I suppose you could set stdin to None, but I'm not sure what that would do or if it would improve anything. -- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 16:01 Message: Logged In: YES user_id=44345 Well, I built from CVS^H^H^HSubversion HEAD at work and tried again. Still got a core dump, but that was a side-effect of calling Py_FatalError. Is that the intended behavior? I guess with a bogus stderr that makes sense, but if stderr happened to be valid at this point, I'd rather have it raise something more meaningful for the user, like SystemError. -- Comment By: Skip Montanaro (montanaro) Date: 2005-11-12 07:18 Message: Logged In: YES user_id=44345 Thanks Neal. I'll check it out at work next week. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-11 01:24 Message: Logged In: YES user_id=33168 This should be fixed in 2.4.3 and CVS (2.3.5 is probably affected too). I remember dealing with directories specifically. Checkout the current sysmodule.c. Here's the checkin: r39652 | nnorwitz | 2005-10-02 18:03:46 -0700 (Sun, 02 Oct 2005) | 5 lines SF bug #887946. Let me know if this bug is different and the patch doesn't solve the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1353504 ] Python drops core when stdin is bogus
Bugs item #1353504, was opened at 2005-11-10 14:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Neal Norwitz (nnorwitz) Summary: Python drops core when stdin is bogus Initial Comment: Someone here at work had the bright idea to execute a Python script from a Solaris 10 ~/.dtprofile file. Apparently, at the time that script is run stdin is bogus. Python core dumps with this gdb backtrace: #0 0x0807d290 in PyDict_SetItem (op=0x815b79c, key=0x8163f20, value=0x0) at ../Objects/dictobject.c:549 #1 0x0807e0f7 in PyDict_SetItemString (v=0x815b79c, key=0x8118df2 "stdin", item=0x0) at ../Objects/dictobject.c:1988 #2 0x080e0d03 in _PySys_Init () at ../Python/sysmodule.c:977 #3 0x080ddfdb in Py_InitializeEx (install_sigs=1) at ../Python/pythonrun.c:190 #4 0x080dfa89 in Py_Initialize () at ../Python/pythonrun.c:283 #5 0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at ../Modules/main.c:418 #6 0x0805ca13 in main (argc=3, argv=0x8047c08) at ../Modules/python.c:23 (This is from 2.4.2, but it also happens in 2.3.4.) Looking at the code in _PySys_Init it calls sysin = PyFile_FromFile(stdin, "", "r", NULL); which returns NULL. In PyFile_FromFile it creates a new PyFileObject, then initializes it by calling a static function, fill_file_fields. This apparently fails, causing a NULL pointer return. Back in _PySys_Init it checks PyErr_Occurred, but fill_file_fields never raised an except. The NULL pointer is passed to PyDict_SetItemString and havoc ensues. I haven't checked CVS, but 2.4 (and probably 2.3) should be fixed. I suggest raising an IOError in fill_file_fields instead of just setting f to NULL and returning it. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 16:16 Message: Logged In: YES user_id=33168 Ok, I understand that part. But if you can't accept input from the user, what can you do? If all you are suggesting is to change Py_FatalError() to raising a SystemError and still exiting, I'm fine with that if it can work. I agree this would probably be nicer too. Or am I still missing your point? Do you want to work on a patch? I'm fine with any improvement, I'm just not sure how much can be done. If you want to improve the error message, that would be good too. -- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 15:57 Message: Logged In: YES user_id=44345 No, we're still discussing stdin. My only point is that what you do might be predicated on whether or not you think you can communicate with the user on stderr. My thought was that if stderr is valid you can raise an exception that prints a traceback. If not, Py_FatalError is your only recourse. Your code checks for the directori-ness of stdin as the first thing, then bails if it is. If it checked to see if stderr was valid first, it could decide to raise SystemError instead of calling Py_FatalError. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 14:08 Message: Logged In: YES user_id=33168 Did you mistype and still mean stdin or are we talking about stderr? IIRC, calling Py_FatalError() was what I intended if stdin is bogus. I don't know what else to do. If you can think of scenarios where we could improve the behaviour, I think that's fine to do. I suppose you could set stdin to None, but I'm not sure what that would do or if it would improve anything. -- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 14:01 Message: Logged In: YES user_id=44345 Well, I built from CVS^H^H^HSubversion HEAD at work and tried again. Still got a core dump, but that was a side-effect of calling Py_FatalError. Is that the intended behavior? I guess with a bogus stderr that makes sense, but if stderr happened to be valid at this point, I'd rather have it raise something more meaningful for the user, like SystemError. -- Comment By: Skip Montanaro (montanaro) Date: 2005-11-12 05:18 Message: Logged In: YES user_id=44345 Thanks Neal. I'll check it out at work next week. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-10 23:24 Message: Logged In: YES user_id=33168 This should be fixed in 2.4.3 and CVS (2.3.5 is probably affected too).
[ python-Bugs-1356969 ] Tix.py class HList missing info_bbox
Bugs item #1356969, was opened at 2005-11-14 19:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1356969&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Ron Provost ([EMAIL PROTECTED]) Assigned to: Martin v. Löwis (loewis) Summary: Tix.py class HList missing info_bbox Initial Comment: class HList in Tix.py is missing the method info_bbox(); though according to the Tix website, it exists and should return a list of coordinates for the bounding box of the list entry whose path is passed into the function as an argument. I added the following bit of code to my python 2.4.2 final release build (Tix.py, line 961) and find that it seems to work just fine. def info_bbox( self, entry ): coords = self.tk.call( self._w, 'info', 'bbox', entry ).split( ' ') return map( int, coords ) I've attached the modified file for examination. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1356969&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs
Bugs item #1338995, was opened at 2005-10-26 18:08
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470
Please note that this 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: Greg Couch (gregcouch)
Assigned to: Nobody/Anonymous (nobody)
Summary: CVS webbrowser.py (1.40) bugs
Initial Comment:
There are two calls to _safequote that are only made on
darwin, aka, Mac OS X. That function is missing.
And the UnixBrowser is missing an & in the "simpler
command" and thus causes python to hang until the
browser is exited (if it wasn't running already).
--
>Comment By: Skip Montanaro (montanaro)
Date: 2005-11-14 22:08
Message:
Logged In: YES
user_id=44345
(Reopening. The webbrowser module still appears broken to me.)
I'm new to this thread, but webbrowser.open() in current SVN
(revision 41445) seems broken to me. This simple statement:
webbrowser.open("somefile.html")
returns True but fails to open the page in my currently running
instance of Safari. Dropping back to Python 2.4.1, it works fine.
I know webbrowser was a huge hack, but at least it appeared to do
basic stuff fine. It would appear that's no longer the case.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-11-09 15:43
Message:
Logged In: YES
user_id=1188172
Fixed in Revision 41419.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-10-31 16:01
Message:
Logged In: YES
user_id=131838
Breaking applications that use webbrowser does not help
application writers. It would be much more useful to me, as
an application writer, if the webbrowser module gave an
error saying it couldn't contact a web browser, rather than
the new behavior of hanging my application. You have yet to
address this common use case.
Running the webbrowser in the background is a contract that
the webbrowser module can't break and still be called the
webbrowser module. I agree that the 2.4.2 version is a
practical hack that should be fixed, but the CVS webbrower
almost fixes it while breaking existing applications. Since
adding an & is so bad (the web browser is already confirmed
to exist and to be executable), the CVS webbrower could be
changed to use the subprocess module instead of os.system,
and the original webbrowser contract could be preserved.
The wrong display or wrong xhost/xauth permissions are not a
problem because the python GUI application that calls
webbrowser would have failed to start up in the first place
if those problems existed. Starting the web browser in the
background only needs to confirm that the web browser
actually started up.
--
Comment By: Oleg Broytmann (phd)
Date: 2005-10-31 07:11
Message:
Logged In: YES
user_id=4799
Yes, I want.
Current practice of running a browser in the background by
default is deadly broken. The old code of webbrowser.py is
full of dirty hacks. Look at Netscape._remote(). It tries to
start a browser to send a remote command; if that fails it
tries to start the browser in the background, waits an
arbitrary number of seconds (why this? why not less? why not
more?) and without testing if the browser in the background
was started it retries sending the remote command. You can
never know if the browser was started and if the command was
sent becuase .open() does not return a result code.
At the global level the bug is that webbrowser.py doesn't
tri all browsers in the tryorder - it only concentrates on
the first it found in PATH. What if the brwoser cannot be
started (damaged disk image; wrong DISAPLY; wrong
xhost/xauth permissions)?
My patched webbrowser.py is much safer. It runs all browsers
in the tryorder until it finds one that can be started. One
doesn't need to wait a random number of seconds, too little
for slow systems, too many for fast. .open() returns a
success/fail status (on systems where it is possible to
obtain one).
The framework still alows you to shoot yourself in the foot,
but you must do it explicitly. Either run
os.system("shotgun-browser &")
yourself or register your own ShotgunBrowser. Thus the new
framework is safe by default but still flexible.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-10-28 13:49
Message:
Logged In: YES
user_id=131838
So you really want to change existing practice and break all
Python GUI programs that invoke webbrowser.open?
And the Elinks example proves my point. What is the point
[ python-Bugs-1337987 ] IDLE, F5 – wrong external file content. (on error!)
Bugs item #1337987, was opened at 2005-10-25 22:12 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: IDLE Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: MvGulik (tyrell_rr) >Assigned to: Kurt B. Kaiser (kbk) >Summary: IDLE, F5 – wrong external file content. (on error!) Initial Comment: IDLE, F5 wrong external file content on error. using: Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32 IDLE 1.0.5 , TK: 8.4 The basic problem is that when a external file is reloaded, by using F5, and that file contains a error. IDLE will tell about the error, and highlight the error, but its still using the old file content in its GUI window and not the newly reloaded file content. when: (IDLE GUI) - using F5 to reload and restart a external script. - new and changed script file containing a error. what: - display is showing previous script content. - error highlight is pointing at the wrong code. (bad!) how: first file: (create, load and execute) --- a = 1 print a --- change to: --- a = 1 print a : print a --- use F5 to auto reload and execute. Anything I'm doing wrong, or I can do locally to fix this?. just let me know. ps: upgrade to 2.4.x is not really a option in my case. (not yet at leased) Cheers M.v.Gulik -- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-15 00:54 Message: Logged In: YES user_id=149084 Duplicate of RFE 1175686. Please read the comments on that Tracker item. IDLE is intended to edit its own code. Apparently you are using an external editor. It's not a high priority for me to support that, since IDLE has one-keystroke save, load and run. The guy who submitted the RFE never came back with a use case; what's your use for this feature? IDLE would have to detect that the file had changed on disk. Not difficult, just not done right now. -- Comment By: MvGulik (tyrell_rr) Date: 2005-10-28 05:46 Message: Logged In: YES user_id=779309 > Save with Control-S before pressing F5. Don't think that a good idee. This will save the initially loaded old file content inside IDLE over the new file content (external edited -> not using IDLE for editing) Effectingly undoing all the changes done with the external editor. M.v.Gulik. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-25 22:45 Message: Logged In: YES user_id=80475 Save with Control-S before pressing F5. -- Comment By: MvGulik (tyrell_rr) Date: 2005-10-25 22:37 Message: Logged In: YES user_id=779309 huu, little update. the error itself is not part of the real (code)problem. ( it is of course when its leading to misleading debug info ) but the display of the external file in just not updated after using F5. with or without a error being triggerd. M.v.Gulik -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1063937 ] Random core dumps
Bugs item #1063937, was opened at 2004-11-10 08:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1063937&group_id=5470 Please note that this 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.2.3 >Status: Closed >Resolution: Works For Me >Priority: 5 Submitted By: munder12 (munder12) >Assigned to: Neal Norwitz (nnorwitz) Summary: Random core dumps Initial Comment: I have narrowed it down as far as I can by continuing to make the problem simpler and simpler but where it still core dumps. The way this is set up is the following: pytest2.py and pytest.py are in the same directory. pytest3.py is in PYTHONPATH where PYTHONPATH is /BASE:/SUP (pytest3.py is in BASE). Run ./pytest2.py several times. This current problem core dumps on average about 2 times every 5 runs. I have attached a file that has the Python listings as well as the gdb traceback. This is running under Fedora Core 1 with: Python 2.2.3 (#1, Oct 15 2003, 23:33:35) [GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] on linux2 Thank you, Mark PS Strangely enough the comments in pytest.py seem to actually increase the frequency of core dumps. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 22:55 Message: Logged In: YES user_id=33168 munder12, if you are still having problems let us know. I'm closing this as not reproducible. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-10-03 02:15 Message: Logged In: YES user_id=1188172 I'd say that it can be closed. As mwh says: "If Python 2.4b2 cored 25% of the time it was launched, someone else would have noticed by now :)" -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 23:42 Message: Logged In: YES user_id=33168 I can't reproduce on current CVS (2.5). Can anyone reproduce this now? Should this be closed? -- Comment By: Nick Coghlan (ncoghlan) Date: 2004-11-23 01:15 Message: Logged In: YES user_id=1038590 I'm not sure it's relevant, but I once had a similar problem with Python flakiness that turned out to be due to some old .pyc files lying around (this was Fedora Core 3-test 1, and the offending files were in my Python CVS build directory). For whatever reason, Python wasn't picking up the version mismatch and was trying to use the old .pyc files. Seg faults abounded as a result. One thought: could root ownership of pre-generated .pyc's have that effect? (I don't know how Python reacts if it can't delete the .pyc's) -- Comment By: munder12 (munder12) Date: 2004-11-17 09:00 Message: Logged In: YES user_id=1156202 I have written a program in C that just opens and closes a file repeatedly. It appears to work fine. But, there appears to be much more that Python is doing behind the scenes than what my script is explicitly directing (open and close the file). Since I'm not sure what all OS related calls Python is making when opening, say, "site.py," I'm not quite sure how I can write a C code that mimics what Python is doing. It may well be that the OS is the culprit. However, it also could be that, in the Python code itself, some error checking is not being performed on all OS calls as they should be since they so rarely fail on a mjority of OS's. Or, extra try...catch blocks maybe could be added to retry the OS call(s) that is "incorrectly" failing on Fedora Core 1 so that Python maintains its portability with (hopefully) minimal speed impact. -- Comment By: Tim Peters (tim_one) Date: 2004-11-16 16:54 Message: Logged In: YES user_id=31435 At this point, it would be prudent to write the same kind of program in straight C, and test that. The more you find out, the less it appears that Python has something to do with what you're seeing. Note that it's not unusual to discover OS, compiler, and platform C library bugs by running Python programs, simply because Python builds on all of them. -- Comment By: munder12 (munder12) Date: 2004-11-16 16:47 Message: Logged In: YES user_id=1156202 It is 2 times out of 8 runs of the main script. Actually, that is 2 cores out of 1600 runs of the script that really cores. It does seem to be localized to Fedora Core 1. Fedora Core 2, Win 2000, Win XP, and Mandrake 9 on similar hardware do not have the problem with these scripts. The Python 2.4b2 is straight out of the tarball (co
