[ python-Feature Requests-1548178 ] Add 'find' method to sequence types
Feature Requests item #1548178, was opened at 2006-08-28 22:47
Message generated for change (Comment added) made by kovan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Closed
Resolution: Rejected
Priority: 4
Submitted By: kovan (kovan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add 'find' method to sequence types
Initial Comment:
In the benefit of Python's readability and simplicity,
a 'find' method could be added to sequence types, that
would return the first item in the list that matches
some criteria.
For example, it's a common practice to use lists of
(key,value) pairs instead of dictionaries when the
sequence must be ordered.
To find an element maching a key in such cases, I
frequently find myself writing (IMHO) too much code for
such a straightforward operation. AFAIK currently there
are two easy ways to do this (shouln't be one, and only
one?):
for item in items:
if item.attribute == key:
foundItem = item
break
else: foundItem = None
OR
foundItems = [item for item in items if item.key == value]
if foundItems:
foundItem = foundItem[0]
IMO, in none of the cases the code is as clear and,
specially, as short, as it should be.
With the find method, the same code would be:
item = items.find(lambda x: x.key == value)
--
>Comment By: kovan (kovan)
Date: 2006-09-06 11:10
Message:
Logged In: YES
user_id=1426755
It's not about performance, it's about code readability and
simplicity for such a common operation.
The index() method is useless here because, as I explained,
it's not a search by value.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-09-06 08:17
Message:
Logged In: YES
user_id=849994
Looking at all those efforts to remove str.find(), I think
this is not going to happen. The sequence API is already
rich enough.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-09-03 21:07
Message:
Logged In: YES
user_id=341410
Lists have an .index(obj[, start[, stop]]) method that tells
you the index of the first object that matches obj, raising
an exception otherwise.
Generally speaking, you can get better performance for
repeated searches by...
dct = {}
for i,(k,v) in enumerate(lst):
dct.setdefault(k, []).append(i)
Then to find the first index...
dct.get(k, [None])[0]
Suggested close.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&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-1548178 ] Add 'find' method to sequence types
Feature Requests item #1548178, was opened at 2006-08-28 20:47
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Closed
Resolution: Rejected
Priority: 4
Submitted By: kovan (kovan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add 'find' method to sequence types
Initial Comment:
In the benefit of Python's readability and simplicity,
a 'find' method could be added to sequence types, that
would return the first item in the list that matches
some criteria.
For example, it's a common practice to use lists of
(key,value) pairs instead of dictionaries when the
sequence must be ordered.
To find an element maching a key in such cases, I
frequently find myself writing (IMHO) too much code for
such a straightforward operation. AFAIK currently there
are two easy ways to do this (shouln't be one, and only
one?):
for item in items:
if item.attribute == key:
foundItem = item
break
else: foundItem = None
OR
foundItems = [item for item in items if item.key == value]
if foundItems:
foundItem = foundItem[0]
IMO, in none of the cases the code is as clear and,
specially, as short, as it should be.
With the find method, the same code would be:
item = items.find(lambda x: x.key == value)
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-09-06 09:18
Message:
Logged In: YES
user_id=849994
What should find() return if nothing is found?
It can't return None since that can be a valid item, so it
has to raise an exception. Therefore,
try:
item = items.find(lambda x: x.key == value)
except WhateverError:
handle
is not much shorter than
try:
item = (x for x in items if x.key == value).next()
except StopIteration:
handle
--
Comment By: kovan (kovan)
Date: 2006-09-06 09:10
Message:
Logged In: YES
user_id=1426755
It's not about performance, it's about code readability and
simplicity for such a common operation.
The index() method is useless here because, as I explained,
it's not a search by value.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-09-06 06:17
Message:
Logged In: YES
user_id=849994
Looking at all those efforts to remove str.find(), I think
this is not going to happen. The sequence API is already
rich enough.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-09-03 19:07
Message:
Logged In: YES
user_id=341410
Lists have an .index(obj[, start[, stop]]) method that tells
you the index of the first object that matches obj, raising
an exception otherwise.
Generally speaking, you can get better performance for
repeated searches by...
dct = {}
for i,(k,v) in enumerate(lst):
dct.setdefault(k, []).append(i)
Then to find the first index...
dct.get(k, [None])[0]
Suggested close.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&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-1548178 ] Add 'find' method to sequence types
Feature Requests item #1548178, was opened at 2006-08-28 22:47
Message generated for change (Comment added) made by kovan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Closed
Resolution: Rejected
Priority: 4
Submitted By: kovan (kovan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add 'find' method to sequence types
Initial Comment:
In the benefit of Python's readability and simplicity,
a 'find' method could be added to sequence types, that
would return the first item in the list that matches
some criteria.
For example, it's a common practice to use lists of
(key,value) pairs instead of dictionaries when the
sequence must be ordered.
To find an element maching a key in such cases, I
frequently find myself writing (IMHO) too much code for
such a straightforward operation. AFAIK currently there
are two easy ways to do this (shouln't be one, and only
one?):
for item in items:
if item.attribute == key:
foundItem = item
break
else: foundItem = None
OR
foundItems = [item for item in items if item.key == value]
if foundItems:
foundItem = foundItem[0]
IMO, in none of the cases the code is as clear and,
specially, as short, as it should be.
With the find method, the same code would be:
item = items.find(lambda x: x.key == value)
--
>Comment By: kovan (kovan)
Date: 2006-09-06 11:25
Message:
Logged In: YES
user_id=1426755
Oh OK, I hadn't thought about the fact that None can be a
valid item in the sequence.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-09-06 11:18
Message:
Logged In: YES
user_id=849994
What should find() return if nothing is found?
It can't return None since that can be a valid item, so it
has to raise an exception. Therefore,
try:
item = items.find(lambda x: x.key == value)
except WhateverError:
handle
is not much shorter than
try:
item = (x for x in items if x.key == value).next()
except StopIteration:
handle
--
Comment By: kovan (kovan)
Date: 2006-09-06 11:10
Message:
Logged In: YES
user_id=1426755
It's not about performance, it's about code readability and
simplicity for such a common operation.
The index() method is useless here because, as I explained,
it's not a search by value.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-09-06 08:17
Message:
Logged In: YES
user_id=849994
Looking at all those efforts to remove str.find(), I think
this is not going to happen. The sequence API is already
rich enough.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-09-03 21:07
Message:
Logged In: YES
user_id=341410
Lists have an .index(obj[, start[, stop]]) method that tells
you the index of the first object that matches obj, raising
an exception otherwise.
Generally speaking, you can get better performance for
repeated searches by...
dct = {}
for i,(k,v) in enumerate(lst):
dct.setdefault(k, []).append(i)
Then to find the first index...
dct.get(k, [None])[0]
Suggested close.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1548371 ] filterwarnings('error') has no effect
Bugs item #1548371, was opened at 2006-08-29 02:27
Message generated for change (Comment added) made by rupole
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548371&group_id=5470
Please note that this 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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: filterwarnings('error') has no effect
Initial Comment:
Once a warning has already been issued,
warnings.filterwarnings('error',...) will not cause an
error to be raised. When the attached script is run,
the warning is printed the first time thru the loop,
but no error is raised the 2nd time thru. Likewise,
warnings.filterwarnings('always',...) will not cause
the warning to be printed again.
--
>Comment By: Roger Upole (rupole)
Date: 2006-09-06 05:52
Message:
Logged In: YES
user_id=771074
That depends on how it's expected to behave when switching
back to a filter that actually needs to check the cache.
Should 'once' mean only one time ever, or should it print
the warning again after the filters are modified ?
If the cache is cleaned up, there's no way to know if the
warning was issued prior to the modification.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-09-06 01:22
Message:
Logged In: YES
user_id=849994
You could go another way and check/cleanup the cache on each
call to filterwarning().
--
Comment By: Roger Upole (rupole)
Date: 2006-09-01 12:19
Message:
Logged In: YES
user_id=771074
Without the cache, the only filters you could possibly
implement would be 'error' and 'ignore'.
--
Comment By: Marien Zwart (marienz)
Date: 2006-09-01 05:44
Message:
Logged In: YES
user_id=857292
The whole point of that cache is to not go through the list
of filters if the warning is in the cache. Why would you
keep the cache around if you search through the filters in
every case anyway?
--
Comment By: Roger Upole (rupole)
Date: 2006-08-31 23:38
Message:
Logged In: YES
user_id=771074
It might be simpler to check if the warning is in the line
cache after the disposition is determined from the filters.
In the case of 'always' and 'error', there's no need to
check the cache at all.
--
Comment By: Marien Zwart (marienz)
Date: 2006-08-31 15:34
Message:
Logged In: YES
user_id=857292
This is caused by the warnings module caching when a
combination of message, Warning subclass and linenumber gets
ignored and bypassing the search through the warning filters
when that same combination occurs again.
I think it is possible to avoid this problem while keeping
the cache by keeping track of the "version" of the filters
list (a simple integer that is incremented every time the
filters list is modified through the functions in the
warnings module) and including this in the key tuple
warn_explicit uses to remember previous ignores. Old stuff
would remain in the cache but that should not be a big
problem (changes to the filters list should not be that common).
Does this sound reasonable? If it does I'll see if I can
produce a patch.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548371&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-1553375 ] Add traceback.print_full_exception()
Feature Requests item #1553375, was opened at 2006-09-06 12:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553375&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Add traceback.print_full_exception() Initial Comment: The suggestion is to add something roughly like this: def print_full_exception(type, value, traceback, file): . _print(sys.stderr, 'Traceback (most recent call last):') . print_stack(traceback.tb_frame.f_back, file=file) . print_tb(traceback, file=file) . . lines = format_exception_only(type, value) . for line in lines[:-1]: . _print(file, line, ' ') . _print(file, lines[-1], '') to the traceback module, to print the exception not just downward from the calling point, but also upward all the way to the top of the stack. This would be useful in, e.g. logging, where exceptions are caught and printed, but right now no information is given as to where they occurred in user code. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553375&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails
Bugs item #1531862, was opened at 2006-07-31 16:53 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 Please note that this 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: John A Meinel (jfmeinel) Assigned to: Gustavo Niemeyer (niemeyer) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py -- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 12:48 Message: Logged In: YES user_id=7887 Wow.. this is strange. I don't see any reason why the build bots would break with this change, except for the reason that the test needs to output data to stdout/stderr to check if it's working or not. Is the buildbot checking these somehow? Is there any additional information about these failures? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 03:59 Message: Logged In: YES user_id=33168 I have reverted both of these changes since all the buildbots were broken. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 02:34 Message: Logged In: YES user_id=33168 This change has broken many (all?) of the buildbots. http://www.python.org/dev/buildbot/all/ -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 02:06 Message: Logged In: YES user_id=7887 Fixed in 51758, backported to 2.5 in 51759. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 01:44 Message: Logged In: YES user_id=7887 Neal, I'm preparing a patch which fixes this problem as well. Anthony, we should really be checking fd numbers, since they're the ones dup'ed in the child. If sys.stdout has a fileno() not in (0, 1, 2), that's not an issue. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-08-16 04:16 Message: Logged In: YES user_id=29957 Making it check for particular FD numbers is a bad idea. Instead, it should check that any FD that's being closed isn't in the set (sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno()) -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-16 04:11 Message: Logged In: YES user_id=33168 If stderr == stdout, this patch won't fix that, will it? Shouldn't you add 1, 2 to the blacklist for stderr? (The patch adds 2, I think 1 may also be required.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails
Bugs item #1531862, was opened at 2006-07-31 16:53 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 Please note that this 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: John A Meinel (jfmeinel) Assigned to: Gustavo Niemeyer (niemeyer) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py -- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 12:52 Message: Logged In: YES user_id=7887 Notice that in all buildbots that reported the failure, subprocess tests still pass correctly. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 12:48 Message: Logged In: YES user_id=7887 Wow.. this is strange. I don't see any reason why the build bots would break with this change, except for the reason that the test needs to output data to stdout/stderr to check if it's working or not. Is the buildbot checking these somehow? Is there any additional information about these failures? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 03:59 Message: Logged In: YES user_id=33168 I have reverted both of these changes since all the buildbots were broken. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 02:34 Message: Logged In: YES user_id=33168 This change has broken many (all?) of the buildbots. http://www.python.org/dev/buildbot/all/ -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 02:06 Message: Logged In: YES user_id=7887 Fixed in 51758, backported to 2.5 in 51759. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 01:44 Message: Logged In: YES user_id=7887 Neal, I'm preparing a patch which fixes this problem as well. Anthony, we should really be checking fd numbers, since they're the ones dup'ed in the child. If sys.stdout has a fileno() not in (0, 1, 2), that's not an issue. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-08-16 04:16 Message: Logged In: YES user_id=29957 Making it check for particular FD numbers is a bad idea. Instead, it should check that any FD that's being closed isn't in the set (sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno()) -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-16 04:11 Message: Logged In: YES user_id=33168 If stderr == stdout, this patch won't fix that, will it? Shouldn't you add 1, 2 to the blacklist for stderr? (The patch adds 2, I think 1 may also be required.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&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-1553380 ] Print full exceptions as they occur in logging
Feature Requests item #1553380, was opened at 2006-09-06 12:57 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=1553380&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Print full exceptions as they occur in logging Initial Comment: Sometimes exceptions occur when using logging that are caused by the user code. However, logging catches these exceptions and does not give a clue as to where the error occurred. Printing full exceptions as suggested in RFE http://www.python.org/sf/1553375 would be a big help. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553380&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-1553380 ] Print full exceptions as they occur in logging
Feature Requests item #1553380, was opened at 2006-09-06 12:57 Message generated for change (Settings changed) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553380&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) >Assigned to: Vinay Sajip (vsajip) Summary: Print full exceptions as they occur in logging Initial Comment: Sometimes exceptions occur when using logging that are caused by the user code. However, logging catches these exceptions and does not give a clue as to where the error occurred. Printing full exceptions as suggested in RFE http://www.python.org/sf/1553375 would be a big help. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553380&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-1553375 ] Add traceback.print_full_exception()
Feature Requests item #1553375, was opened at 2006-09-06 12:48 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553375&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Add traceback.print_full_exception() Initial Comment: The suggestion is to add something roughly like this: def print_full_exception(type, value, traceback, file): . _print(sys.stderr, 'Traceback (most recent call last):') . print_stack(traceback.tb_frame.f_back, file=file) . print_tb(traceback, file=file) . . lines = format_exception_only(type, value) . for line in lines[:-1]: . _print(file, line, ' ') . _print(file, lines[-1], '') to the traceback module, to print the exception not just downward from the calling point, but also upward all the way to the top of the stack. This would be useful in, e.g. logging, where exceptions are caught and printed, but right now no information is given as to where they occurred in user code. -- >Comment By: Michael Hoffman (hoffmanm) Date: 2006-09-06 12:59 Message: Logged In: YES user_id=987664 Hmmm, my indentation didn't work very well. Hopefully you should be able to figure it out though. :) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553375&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-1553375 ] Add traceback.print_full_exception()
Feature Requests item #1553375, was opened at 2006-09-06 12:48 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553375&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Add traceback.print_full_exception() Initial Comment: The suggestion is to add something roughly like this: def print_full_exception(type, value, traceback, file): . _print(sys.stderr, 'Traceback (most recent call last):') . print_stack(traceback.tb_frame.f_back, file=file) . print_tb(traceback, file=file) . . lines = format_exception_only(type, value) . for line in lines[:-1]: . _print(file, line, ' ') . _print(file, lines[-1], '') to the traceback module, to print the exception not just downward from the calling point, but also upward all the way to the top of the stack. This would be useful in, e.g. logging, where exceptions are caught and printed, but right now no information is given as to where they occurred in user code. -- >Comment By: Michael Hoffman (hoffmanm) Date: 2006-09-06 13:04 Message: Logged In: YES user_id=987664 Here's some test code that might indicate how this is useful: def x(n=0): .try: ..y(n+1) .except: ..ei = sys.exc_info() ..print_full_exception(ei[0], ei[1], ei[2], sys.stderr) def y(n): .if n > 10: ..raise IOError, "test" . .x(n+1) x() -- Comment By: Michael Hoffman (hoffmanm) Date: 2006-09-06 12:59 Message: Logged In: YES user_id=987664 Hmmm, my indentation didn't work very well. Hopefully you should be able to figure it out though. :) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1553375&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1553496 ] logging.handlers.RotatingFileHandler - inconsistent mode
Bugs item #1553496, was opened at 2006-09-06 11:03 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=1553496&group_id=5470 Please note that this 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: Walker Hale (walkerh) Assigned to: Nobody/Anonymous (nobody) Summary: logging.handlers.RotatingFileHandler - inconsistent mode Initial Comment: RotatingFileHandler does not remember the mode used to open files. By default it will initially open its file with 'a', but client code may set this to something else. After rollover, the mode for the new file changes to 'w'. The behavior is inconsistent with the interface. At the very least the docstring for __init__ should change to show that the mode parameter is not respected after rollover. This affects previous versions. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553496&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1553496 ] logging.handlers.RotatingFileHandler - inconsistent mode
Bugs item #1553496, was opened at 2006-09-06 12:03 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553496&group_id=5470 Please note that this 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: Walker Hale (walkerh) >Assigned to: Vinay Sajip (vsajip) Summary: logging.handlers.RotatingFileHandler - inconsistent mode Initial Comment: RotatingFileHandler does not remember the mode used to open files. By default it will initially open its file with 'a', but client code may set this to something else. After rollover, the mode for the new file changes to 'w'. The behavior is inconsistent with the interface. At the very least the docstring for __init__ should change to show that the mode parameter is not respected after rollover. This affects previous versions. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553496&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1544295 ] Fix Lib/test/test___all__.py
Bugs item #1544295, was opened at 2006-08-21 20:12 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544295&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and Tools Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hasan Diwan (hdiwan650) Assigned to: Nobody/Anonymous (nobody) Summary: Fix Lib/test/test___all__.py Initial Comment: There's a comment saying: # In case _socket fails to build, make this test fail more gracefully # than an AttributeError somewhere deep in CGIHTTPServer. The proposed fix is attached. Applies to revision 51453. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-09-06 13:38 Message: Logged In: YES user_id=11375 Please explain more clearly what the problem is. Does the existing code not work? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544295&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1553577 ] datetime.datetime.now() mangles tzinfo
Bugs item #1553577, was opened at 2006-09-06 13:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&group_id=5470
Please note that this 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: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime.datetime.now() mangles tzinfo
Initial Comment:
When using the pytz package (http://pytz.sf.net/) to create
timezone info objects datetime.datetime.now() behaves
differently than the regular datetime.datetime()
contstructor. Here's an example:
>>> import pytz
>>> info = pytz.timezone("US/Central")
>>> info
>>> import datetime
>>> now = datetime.datetime.now(tz=info)
>>> now
datetime.datetime(2006, 9, 6, 12, 44, 18, 983849,
tzinfo=)
>>> t2 = datetime.datetime(2006, 9, 6, 12, 44, 18,
983849, tzinfo=info)
>>> t2
datetime.datetime(2006, 9, 6, 12, 44, 18, 983849,
tzinfo=)
>>> now.tzinfo == info
False
>>> t2.tzinfo == info
True
It appears that datetime.datetime.now() makes an
off-by-one-hour copy of the timezone info it was passed.
I've reproduced this on 2.4.3 and 2.5c1 as of August 17.
(It's also a little annoying that the timezone arg for
datetime.datetime.now() is "tz" while the timezone arg for
datetime.datetime() is "tzinfo". Is there a good
reason for
them to be different?)
Skip
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1496561 ] Building Python 2.4.3 on Solaris 9/10 with Sun Studio 11
Bugs item #1496561, was opened at 2006-05-28 22:35
Message generated for change (Comment added) made by andyfloe
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496561&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Extension Modules
Group: Python 2.4
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Andreas (andyfloe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Building Python 2.4.3 on Solaris 9/10 with Sun Studio 11
Initial Comment:
If Python 2.4.3 is build on Solaris 9 or 10 with Sun
Studio 11 [cc: Sun C 5.8 2005/10/13], some of the tests
of roundup fail with a core dump of Python. If build
with gcc [gcc (GCC) 3.4.3
(csl-sol210-3_4-branch+sol_rpath)] all runs as expected.
I have compiled Python and bsd 4.3 on Solaris with Sun
Studio as follows:
##-- rebuild Berkeley DB version 4.3.29
URL='http://www.sleepycat.com'
BUILDDIR=/builddir
SRCDIR=/mnt/a
VERSION=4.3.29
PKG=db
STAR="${PKG}"-"${VERSION}".tar.gz
cd "$BUILDDIR"
gunzip -d -c "${SRCDIR}"/"${STAR}" | tar xvf -
cd "${PKG}-${VERSION}"
PREFIX=/opt/db4
CC=cc; export CC
CXX=CC; export CXX
PATH=/opt/SUNWspro/bin:/usr/ccs/bin:/usr/sbin:/usr/bin;
export PATH
unset LD_LIBRARY_PATH
TIMESTAMP=`date +%Y%m%d%H%M%S`
cd build_unix
../dist/configure --prefix="${PREFIX}" \
--enable-compat185 --disable-dump185 \
--enable-shared --enable-static --enable-cxx 2>&1 | \
tee /var/tmp/"${PKG}-${VERSION}"_configure_${TIMESTAMP}
make 2>&1 | tee
/var/tmp/"${PKG}-${VERSION}"_make_${TIMESTAMP}
##- install
## done as user 'root'
#- source the above environment variables
cd "$BUILDDIR"/"${PKG}"-"${VERSION}"/build_unix
make install 2>&1 | \
tee /var/tmp/"${PKG}-${VERSION}"_make_install_`date
'+%Y%m%d%H%M%S'`
cd ..
LIBS='
/opt/db4/lib/libdb-4.3.so
/opt/db4/lib/libdb-4.3.la
/opt/db4/lib/libdb_cxx-4.3.so
/opt/db4/lib/libdb_cxx-4.3.la
/opt/db4/lib/libdb-4.3.a
/opt/db4/lib/libdb.a
/opt/db4/lib/libdb_cxx-4.3.a
/opt/db4/lib/libdb_cxx.a
/opt/db4/lib/libdb_cxx.so
'
ls -l $LIBS
chown root:root $LIBS
chmod 755 $LIBS
cd /usr/include
## the setup.py script in the Python source only looks
for specific
## locations for the header file for the bsddb
ln -s /opt/db4/include /usr/include/db4
# chmod 755 /usr/lib/libdb*.so
##- installing Python 2.4.3
BUILDDIR=/builddir
SRCDIR=/mnt/a
VERSION=2.4.3
STAR=Python-2.4.3.tar.bz2
PKG=`echo $STAR | sed -e '[EMAIL PROTECTED]@@' -e '[EMAIL PROTECTED]@@'
-e '[EMAIL PROTECTED]@@' `
CC=cc; export CC
CXX=CC; export CXX
PATH=/opt/SUNWspro/bin:/usr/ccs/bin:/usr/bin/:/opt/db4/bin:/sbin/bin;
export PATH
LDFLAGS='-R/opt/db4/lib -L/opt/db4/lib'; export LDFLAGS
CPPFLAGS='-I/opt/db4/include'; export CPPFLAGS
cd $BUILDDIR
bunzip2 -c $SRCDIR/$STAR | /usr/sfw/bin/gtar -xvf -
cd "$PKG"
patch -p0 < /mnt/a/python_curses_1471938.patch
./configure --prefix=/usr --without-gcc \
| tee
/var/tmp/"${PKG}"-"$VERSION"_configure_`date
'+%Y%m%d%H%M%S'`
make | tee /var/tmp/"${PKG}"-"$VERSION"_make_`date
'+%Y%m%d%H%M%S'`
make test | tee
/var/tmp/"${PKG}"-"$VERSION"_make_test_`date
'+%Y%m%d%H%M%S'`
# done as user 'root'
cd $BUILDDIR/"$PKG"
make install | tee
/var/tmp/"${PKG}"-"$VERSION"_make_install_`date
'+%Y%m%d%H%M%S'`
All Python 2.4.3 test run OK, see
256 tests OK.
CAUTION: stdout isn't compared in verbose mode:
a test that passes in verbose mode may fail without it.
1 test failed:
test_nis
34 tests skipped:
test_aepack test_al test_applesingle test_bsddb185
test_bsddb3
test_cd test_cl test_codecmaps_cn test_codecmaps_hk
test_codecmaps_jp test_codecmaps_kr
test_codecmaps_tw test_curses
test_gdbm test_gl test_imgfile test_linuxaudiodev
test_locale
test_macfs test_macostools test_normalization
test_ossaudiodev
test_pep277 test_plistlib test_scriptpackages
test_socket_ssl
test_socketserver test_tcl test_timeout
test_unicode_file
test_urllib2net test_urllibnet test_winreg
test_winsound
2 skips unexpected on sunos5:
test_tcl test_locale
If running the tests of the software package roundup
1.1.2 if reveive a core dump from the Python interpreter.
-bash-3.00$ python ./run_tests.py
Running unit tests at level 1
Running unit tests from
/export/home/builddir/roundup-1.1.2/.
Including anydbm tests
Skipping metakit tests
Skipping mysql tests
Skipping postgresql tests
Including sqlite tests
Skipping tsearch2 tests
testDontRetireAdminOrAnonymous
(test.test_actions.RetireActionTestCase) ... ok
testNoPermission
(test.test_actions.RetireActionTestCase) ... ok
testRetireAction
(test.test_actions.RetireActionTestCase) ... ok
testNoPermission
(test.test_actions.StandardSearchActionTestCase) ... ok
testQueryName
(test.test_actions.StandardSearchActionTestCase) ... ok
testEmptyKey (test.test_actions.FakeFilterVarsTestCase)
... ok
testEmptyMultilink
(test.test_actions.FakeFilterVarsTestCase) ... ok
testNonEmptyMultilink
[ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails
Bugs item #1531862, was opened at 2006-07-31 16:53 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 Please note that this 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: Closed Resolution: None Priority: 5 Submitted By: John A Meinel (jfmeinel) Assigned to: Gustavo Niemeyer (niemeyer) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py -- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-07 00:50 Message: Logged In: YES user_id=7887 Problem fixed again in 51797 (trunk) and 51794 (2.5), after removing tests which were offending buildbot due to sys.stdout being set to a StringIO. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 12:52 Message: Logged In: YES user_id=7887 Notice that in all buildbots that reported the failure, subprocess tests still pass correctly. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 12:48 Message: Logged In: YES user_id=7887 Wow.. this is strange. I don't see any reason why the build bots would break with this change, except for the reason that the test needs to output data to stdout/stderr to check if it's working or not. Is the buildbot checking these somehow? Is there any additional information about these failures? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 03:59 Message: Logged In: YES user_id=33168 I have reverted both of these changes since all the buildbots were broken. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 02:34 Message: Logged In: YES user_id=33168 This change has broken many (all?) of the buildbots. http://www.python.org/dev/buildbot/all/ -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 02:06 Message: Logged In: YES user_id=7887 Fixed in 51758, backported to 2.5 in 51759. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 01:44 Message: Logged In: YES user_id=7887 Neal, I'm preparing a patch which fixes this problem as well. Anthony, we should really be checking fd numbers, since they're the ones dup'ed in the child. If sys.stdout has a fileno() not in (0, 1, 2), that's not an issue. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-08-16 04:16 Message: Logged In: YES user_id=29957 Making it check for particular FD numbers is a bad idea. Instead, it should check that any FD that's being closed isn't in the set (sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno()) -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-16 04:11 Message: Logged In: YES user_id=33168 If stderr == stdout, this patch won't fix that, will it? Shouldn't you add 1, 2 to the blacklist for stderr? (The patch adds 2, I think 1 may also be required.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1553819 ] Class instance apparently not destructed when expected
Bugs item #1553819, was opened at 2006-09-06 23: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=1553819&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Peter Donis (peterdonis) Assigned to: Nobody/Anonymous (nobody) Summary: Class instance apparently not destructed when expected Initial Comment: When an instance variable of a class with the same name as a class variable in a base class is assigned a value (making the class variable of the base class invisible), the class instance does not appear to be destructed when it should. Here is the simplest test script I've been able to come up with that reproduces the error, along with its output when run from a shell prompt. I've included the dir() commands to make sure that the variable referencing the class instance is in fact deleted in both cases. As you can see, the instance of the base class gets destructed as expected, but the instance of the derived class does not. --- Test script --- #!/usr/bin/env python # Test script to see when objects are freed class Test(object): testfield = None def __init__(self): print "Initializing test object." def __del__(self): print "Freeing test object." class Test2(Test): def __init__(self): # This masks Test.testfield self.testfield = self.meth Test.__init__(self) def meth(self): pass print dir() t = Test() print dir() del t print dir() t2 = Test2() print dir() del t2 print dir() --- Output --- $ python deltest.py ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] Initializing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func', 't'] Freeing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] Initializing test object. ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func', 't2'] ['Test', 'Test2', '__builtins__', '__doc__', '__file__', '__name__', 'func'] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553819&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
