[ python-Bugs-1591319 ] replace groups doesn't work in this special case
Bugs item #1591319, was opened at 2006-11-06 12:49
Message generated for change (Comment added) made by tomek74
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591319&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: Regular Expressions
Group: Python 2.4
Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Thomas K. (tomek74)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: replace groups doesn't work in this special case
Initial Comment:
If you have a regular expression like this:
([0-9])([a-z])?
matching this string:
1 1a
and replacing with this:
yx
you get what expected:
yx yx
BUT:
If you replace with this:
\1\2
you get nothing replaced, because the group \2
doesn't exist for the pattern "1".
But it does exist for the pattern "1a"!
We have multiple possibilities here:
1.) The string "1" gives no result, because \2
doesn't exist. The string "1a" gives a result, so the
output should be: 1a
2.) The sring "1" gives a result, because \2 is
handled like an empty string. The string "1a" gives a
result, so the output should be: 1 1a
I think the case that the sring "1" has no results,
but effects the string "1a" wich would normaly have a
result, is bad.
What are your thoughts on it?
Test code:
import re
# common variables
rawstr = r"""([0-9])([a-z])?"""
embedded_rawstr = r"""([0-9])([a-z])?"""
matchstr = """1 1a"""
# method 1: using a compile object
compile_obj = re.compile(rawstr)
match_obj = compile_obj.search(matchstr)
# method 2: using search function (w/ external flags)
match_obj = re.search(rawstr, matchstr)
# method 3: using search function (w/ embedded flags)
match_obj = re.search(embedded_rawstr, matchstr)
# Retrieve group(s) from match_obj
all_groups = match_obj.groups()
# Retrieve group(s) by index
group_1 = match_obj.group(1)
group_2 = match_obj.group(2)
# Replace string
newstr = compile_obj.subn('\1\2', 0)
--
>Comment By: Thomas K. (tomek74)
Date: 2006-11-07 11:36
Message:
Logged In: YES
user_id=22427
I verified your code. It works for me, too.
Sorry.
--
Comment By: Gustavo Niemeyer (niemeyer)
Date: 2006-11-06 13:17
Message:
Logged In: YES
user_id=7887
Hello Thomas,
I don't understand exactly what you mean here.
This doesn't work:
>>> re.compile("([0-9])([a-z])?").subn(r"<\1\2>", "1 1a")
Traceback (most recent call last):
...
sre_constants.error: unmatched group
And this works fine:
>>> re.compile("([0-9])([a-z]?)").subn(r"<\1\2>", "1 1a")
('<1> <1a>', 2)
The example code you provided doesn't run here, because
'subn()' is being provided
bad data (check http://docs.python.org/lib/node46.html for
docs). It's also
being passed '\1\2', which is really '\x01\x02', and won't
do what you want.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591319&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method
Bugs item #1105286, was opened at 2005-01-19 16:04
Message generated for change (Comment added) made by yohell
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: YoHell (yohell)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Undocumented implicit strip() in split(None) string method
Initial Comment:
Hi!
I noticed that the string method split() first does an
implicit strip() before splitting when it's used with
no arguments or with None as the separator (sep in the
docs). There is no mention of this implicit strip() in
the docs.
Example 1:
s = " word1 word2 "
s.split() then returns ['word1', 'word2'] and not ['',
'word1', 'word2', ''] as one might expect.
WHY IS THIS BAD?
1. Because it's undocumented. See:
http://www.python.org/doc/current/lib/string-methods.html#l2h-197
2. Because it may lead to unexpected behavior in programs.
Example 2:
FASTA sequence headers are one line descriptors of
biological sequences and are on this form:
">" + Identifier + whitespace + free text description.
Let sHeader be a Python string containing a FASTA
header. One could then use the following syntax to
extract the identifier from the header:
sID = sHeader[1:].split(None, 1)[0]
However, this does not work if sHeader contains a
faulty FASTA header where the identifier is missing or
consists of whitespace. In that case sID will contain
the first word of the free text description, which is
not the desired behavior.
WHAT SHOULD BE DONE?
The implicit strip() should be removed, or at least
should programmers be given the option to turn it off.
At the very least it should be documented so that
programmers have a chance of adapting their code to it.
Thank you for an otherwise splendid language!
/Joel Hedlund
Ph.D. Student
IFM Bioinformatics
Link�ping University
--
>Comment By: YoHell (yohell)
Date: 2006-11-07 15:06
Message:
Logged In: YES
user_id=1008220
I'm opening this again, since the docs still don't reflect
the behavior of the method.
from the docs:
"""
If sep is not specified or is None, a different splitting
algorithm is applied. First, whitespace characters (spaces,
tabs, newlines, returns, and formfeeds) are stripped from
both ends.
"""
This is not true when maxsplit is given.
Example:
>>> " foo bar ".split(None)
['foo', 'bar']
>>> " foo bar ".split(None, 1)
['foo', 'bar ']
Whitespace is obviously not stripping whitespace from the
ends of the string before splitting the rest of the string.
--
Comment By: Wummel (calvin)
Date: 2005-01-24 13:51
Message:
Logged In: YES
user_id=9205
This should probably also be added to rsplit()?
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-01-24 08:15
Message:
Logged In: YES
user_id=593130
To me, the removal of whitespace at the ends (stripping) is
consistent with the removal (or collapsing) of extra
whitespace in between so that .split() does not return empty
words anywhere. Consider:
>>> ',1,,2,'.split(',')
['', '1', '', '2', '']
If ' 1 2 '.split() were to return null strings at the beginning
and end of the list, then to be consistent, it should also put
one in the middle. One can get this by being explicit (mixed
WS can be handled by translation):
>>> ' 1 2 '.split(' ')
['', '1', '', '2', '']
Having said this, I also agree that the extra words proposed
by jj are helpful.
BUG?? In 2.2, splitting an empty or whitespace only string
produces an empty list [], not a list with a null word [''].
>>> ''.split()
[]
>>> ' '.split()
[]
which is what I see as consistent with the rest of the no-null-
word behavior. Has this changed since? (Yes, must
upgrade.) I could find no indication of such change in either
the tracker or CVS.
--
Comment By: YoHell (yohell)
Date: 2005-01-20 15:59
Message:
Logged In: YES
user_id=1008220
Brilliant, guys!
Thanks again for a superb scripting language, and with
documentation to match!
Take care!
/Joel Hedlund
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-20 15:50
Message:
Logged In: YES
user_id=80475
The prosposed wording is fine.
If there are no objections or concerns, I'll apply it soon.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2005-01-20 15:28
Message:
Logged In: YES
user_id=764593
Replacing the quoted line:
"""
...
If sep is
[ python-Bugs-1567234 ] unchecked metaclass mro
Bugs item #1567234, was opened at 2006-09-28 14:48
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567234&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: ganges master (gangesmaster)
Assigned to: A.M. Kuchling (akuchling)
Summary: unchecked metaclass mro
Initial Comment:
this bug was fixed in python2.5, but it's worth adding
to 2.4.4.
metaclasses can return an "insane" mro, which confuses
the PyXXX_Check checks, and causes memory corruption.
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> class crasher(object):
... class __metaclass__(type):
... def mro(self):
... return (str, int, list)
...
>>> c = crasher("hello")
>>> c # a very strange object
''
>>> dir(c)
[]
>>> c.append(5)
#
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2006-11-07 09:06
Message:
Logged In: YES
user_id=11375
This bugfix didn't make it into Python 2.4.4, and Anthony
Baxter suggests there probably won't be a 2.4.5 release, so
I'm closing this bug. Sorry it didn't work out.
--
Comment By: ganges master (gangesmaster)
Date: 2006-09-29 09:12
Message:
Logged In: YES
user_id=1406776
i never managed working with svn's or cvs's... i can point
you to the official source distribution of 2.4.2:
file: typeobject.c
function: static int mro_internal(PyTypeObject *type)
+-+-+-+-+-+-+-+-
mro = lookup_method((PyObject *)type, "mro", &mro_str);
if (mro == NULL)
return -1;
result = PyObject_CallObject(mro, NULL);
Py_DECREF(mro);
}
if (result == NULL)
return -1;
tuple = PySequence_Tuple(result);
+-+-+-+-+-+-+-+-+-
python 2.5 (release) added the following check:
+-+-+-+-+-+-+-+-+-
if (!PyType_IsSubtype(solid, solid_base(t))) {
PyErr_Format(PyExc_TypeError,
"mro() returned base with unsuitable layout ('%.500s')",
t->tp_name);
+-+-+-+-+-+-+-+-+-
that's the best i can do, sorry
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-09-29 08:32
Message:
Logged In: YES
user_id=11375
Can you please provide a reference to the original bug, or
to the revision that fixes the bug in 2.5?
+
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567234&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method
Bugs item #1105286, was opened at 2005-01-19 16:04
Message generated for change (Comment added) made by yohell
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: YoHell (yohell)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Undocumented implicit strip() in split(None) string method
Initial Comment:
Hi!
I noticed that the string method split() first does an
implicit strip() before splitting when it's used with
no arguments or with None as the separator (sep in the
docs). There is no mention of this implicit strip() in
the docs.
Example 1:
s = " word1 word2 "
s.split() then returns ['word1', 'word2'] and not ['',
'word1', 'word2', ''] as one might expect.
WHY IS THIS BAD?
1. Because it's undocumented. See:
http://www.python.org/doc/current/lib/string-methods.html#l2h-197
2. Because it may lead to unexpected behavior in programs.
Example 2:
FASTA sequence headers are one line descriptors of
biological sequences and are on this form:
">" + Identifier + whitespace + free text description.
Let sHeader be a Python string containing a FASTA
header. One could then use the following syntax to
extract the identifier from the header:
sID = sHeader[1:].split(None, 1)[0]
However, this does not work if sHeader contains a
faulty FASTA header where the identifier is missing or
consists of whitespace. In that case sID will contain
the first word of the free text description, which is
not the desired behavior.
WHAT SHOULD BE DONE?
The implicit strip() should be removed, or at least
should programmers be given the option to turn it off.
At the very least it should be documented so that
programmers have a chance of adapting their code to it.
Thank you for an otherwise splendid language!
/Joel Hedlund
Ph.D. Student
IFM Bioinformatics
Link�ping University
--
>Comment By: YoHell (yohell)
Date: 2006-11-07 15:11
Message:
Logged In: YES
user_id=1008220
*resubmission: grammar corrected*
I'm opening this again, since the docs still don't reflect
the behavior of the method.
from the docs:
"""
If sep is not specified or is None, a different splitting
algorithm is applied. First, whitespace characters (spaces,
tabs, newlines, returns, and formfeeds) are stripped from
both ends.
"""
This is not true when maxsplit is given.
Example:
>>> " foo bar ".split(None)
['foo', 'bar']
>>> " foo bar ".split(None, 1)
['foo', 'bar ']
Whitespace is obviously not stripped from the ends before
the rest of the string is split.
--
Comment By: YoHell (yohell)
Date: 2006-11-07 15:06
Message:
Logged In: YES
user_id=1008220
I'm opening this again, since the docs still don't reflect
the behavior of the method.
from the docs:
"""
If sep is not specified or is None, a different splitting
algorithm is applied. First, whitespace characters (spaces,
tabs, newlines, returns, and formfeeds) are stripped from
both ends.
"""
This is not true when maxsplit is given.
Example:
>>> " foo bar ".split(None)
['foo', 'bar']
>>> " foo bar ".split(None, 1)
['foo', 'bar ']
Whitespace is obviously not stripping whitespace from the
ends of the string before splitting the rest of the string.
--
Comment By: Wummel (calvin)
Date: 2005-01-24 13:51
Message:
Logged In: YES
user_id=9205
This should probably also be added to rsplit()?
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-01-24 08:15
Message:
Logged In: YES
user_id=593130
To me, the removal of whitespace at the ends (stripping) is
consistent with the removal (or collapsing) of extra
whitespace in between so that .split() does not return empty
words anywhere. Consider:
>>> ',1,,2,'.split(',')
['', '1', '', '2', '']
If ' 1 2 '.split() were to return null strings at the beginning
and end of the list, then to be consistent, it should also put
one in the middle. One can get this by being explicit (mixed
WS can be handled by translation):
>>> ' 1 2 '.split(' ')
['', '1', '', '2', '']
Having said this, I also agree that the extra words proposed
by jj are helpful.
BUG?? In 2.2, splitting an empty or whitespace only string
produces an empty list [], not a list with a null word [''].
>>> ''.split()
[]
>>> ' '.split()
[]
which is what I see as consistent with the rest of the no-null-
word behavior. Has this changed since? (Yes, must
upgrade.) I could find no indication of such change in either
the tracker or CVS.
---
[ python-Bugs-893250 ] curses getkey() crash in raw mode
Bugs item #893250, was opened at 2004-02-09 02:11
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893250&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: J. David Lee (bogjohnson)
Assigned to: A.M. Kuchling (akuchling)
Summary: curses getkey() crash in raw mode
Initial Comment:
Using python 2.3.3 on gentoo I have the following problem:
When calling stdscr.getkey() in raw mode, the program
crashes on a terminal resize event. In cooked and
cbreak modes, the proper string is returned -
"KEY_RESIZE". This problem appeared after upgrading
from python 2.3.2, I believe. Below is a quick program
that exhibits this behavior on my machine.
###
#!/usr/bin/env python
import curses;
stdscr = curses.initscr();
curses.raw();
curses.noecho();
stdscr.keypad(1);
while(1):
stdscr.clear();
stdscr.addstr("Enter key: ");
c = stdscr.getkey();
if(c == 'q'):
break;
stdscr.clear();
stdscr.addstr('"' + c + '"\n\n');
stdscr.addstr("Press any key...");
stdscr.getkey();
curses.noraw();
curses.endwin();
###
A couple of other notes:
1) No exception is thrown (a try block doesn't catch it).
2) The behavior is the same using the interactive
interpreter.
3) The traceback is: File "./keyname", line 19, in ?
stdscr.getkey(); _curses.error: no input
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2006-11-07 09:32
Message:
Logged In: YES
user_id=11375
After experimenting a bit with the attached test program, it
doesn't seem as if this is actually a bug in
the module; the ncurses docs themselves are vague on the
interaction between signals and a KEY_RESIZE. So I'll close
this bug, because it doesn't look like there's anything in
Python to fix.
--
Comment By: J. David Lee (bogjohnson)
Date: 2004-04-20 01:21
Message:
Logged In: YES
user_id=971407
That Gentoo updated the ncurses library is quite possible.
Though the behavior is still incorrect as the documentation
says that getkey will return "KEY_RESIZE" on a terminal
resize event, and in fact it does in cooked and cbreak
modes, but throws an exception when in raw mode (though a
terminal resize isn't an exceptional circumstance). Also, a
program can't assume that an exception on getkey() is a
resize event because an actual exception might occur and
need to be dealt with.
For the present, though, the workaround is acceptable
because a real exception on getkey is very unlikely, as far
as I can see.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2004-04-19 08:45
Message:
Logged In: YES
user_id=11375
1) and 3) are contradictory; 3 is certainly an exception
traceback.
When I try the test program on a Debian system, I get the
same error,
but a try:except: around the getkey() on line 19 lets the
program continue running.
Nothing in the Python curses module changed between 2.3.3
and 2.3.2. Did gentoo switch to a new revision of the
ncurses library, perhaps?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893250&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-893250 ] curses getkey() crash in raw mode
Bugs item #893250, was opened at 2004-02-09 02:11
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893250&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: J. David Lee (bogjohnson)
Assigned to: A.M. Kuchling (akuchling)
Summary: curses getkey() crash in raw mode
Initial Comment:
Using python 2.3.3 on gentoo I have the following problem:
When calling stdscr.getkey() in raw mode, the program
crashes on a terminal resize event. In cooked and
cbreak modes, the proper string is returned -
"KEY_RESIZE". This problem appeared after upgrading
from python 2.3.2, I believe. Below is a quick program
that exhibits this behavior on my machine.
###
#!/usr/bin/env python
import curses;
stdscr = curses.initscr();
curses.raw();
curses.noecho();
stdscr.keypad(1);
while(1):
stdscr.clear();
stdscr.addstr("Enter key: ");
c = stdscr.getkey();
if(c == 'q'):
break;
stdscr.clear();
stdscr.addstr('"' + c + '"\n\n');
stdscr.addstr("Press any key...");
stdscr.getkey();
curses.noraw();
curses.endwin();
###
A couple of other notes:
1) No exception is thrown (a try block doesn't catch it).
2) The behavior is the same using the interactive
interpreter.
3) The traceback is: File "./keyname", line 19, in ?
stdscr.getkey(); _curses.error: no input
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2006-11-07 09:36
Message:
Logged In: YES
user_id=11375
Forgot to attach the script I was using.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-11-07 09:32
Message:
Logged In: YES
user_id=11375
After experimenting a bit with the attached test program, it
doesn't seem as if this is actually a bug in
the module; the ncurses docs themselves are vague on the
interaction between signals and a KEY_RESIZE. So I'll close
this bug, because it doesn't look like there's anything in
Python to fix.
--
Comment By: J. David Lee (bogjohnson)
Date: 2004-04-20 01:21
Message:
Logged In: YES
user_id=971407
That Gentoo updated the ncurses library is quite possible.
Though the behavior is still incorrect as the documentation
says that getkey will return "KEY_RESIZE" on a terminal
resize event, and in fact it does in cooked and cbreak
modes, but throws an exception when in raw mode (though a
terminal resize isn't an exceptional circumstance). Also, a
program can't assume that an exception on getkey() is a
resize event because an actual exception might occur and
need to be dealt with.
For the present, though, the workaround is acceptable
because a real exception on getkey is very unlikely, as far
as I can see.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2004-04-19 08:45
Message:
Logged In: YES
user_id=11375
1) and 3) are contradictory; 3 is certainly an exception
traceback.
When I try the test program on a Debian system, I get the
same error,
but a try:except: around the getkey() on line 19 lets the
program continue running.
Nothing in the Python curses module changed between 2.3.3
and 2.3.2. Did gentoo switch to a new revision of the
ncurses library, perhaps?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893250&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1591122 ] problem building python in vs8express
Bugs item #1591122, was opened at 2006-11-06 04:31 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Thomas Southern (thomashsouthern) Assigned to: Nobody/Anonymous (nobody) Summary: problem building python in vs8express Initial Comment: When I tried to build pythoncore in vc++8 express, it worked without a hitch until the link stage when i got an unresolved external _init_types. Python compiles just fine and pythonw compiles up to the link where it comes accross the same error. If I am suppose to contact someone else about my issue please sent me in the wright direction. my email is [EMAIL PROTECTED] -- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-07 15:41 Message: Logged In: YES user_id=849994 So could you please retry with the SVN HEAD? -- Comment By: Thomas Southern (thomashsouthern) Date: 2006-11-07 00:59 Message: Logged In: YES user_id=1638546 I am using python 2.5 -- Comment By: Georg Brandl (gbrandl) Date: 2006-11-06 07:46 Message: Logged In: YES user_id=849994 Which version of the sources are you using? I think this is fixed in the SVN HEAD. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1592241 ] Stepping into a generator throw does not work
Bugs item #1592241, was opened at 2006-11-07 12:05 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=1592241&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bernhard Mulder (bwmulder) Assigned to: Nobody/Anonymous (nobody) Summary: Stepping into a generator throw does not work Initial Comment: Python version: 2.6 Platform: Windows XP Stepping into a throw of an iterator with the debugger does not work. To reproduce: 1. Run the attached script 2. type 's' for single step once you see the debugger prompt. I am getting this backtrace: File "C:\bwm\Cruiser\play\microthreads\post.py", line 24, in it.throw(E, E()) File "C:\bwm\Cruiser\play\microthreads\post.py", line 7, in f1 (yield (2,(self.f2,(exc_class, File "C:\Python25\lib\bdb.py", line 50, in trace_dispatch return self.dispatch_call(frame, arg) File "C:\Python25\lib\bdb.py", line 79, in dispatch_call self.user_call(frame, arg) File "C:\Python25\lib\pdb.py", line 134, in user_call self.interaction(frame, None) File "C:\Python25\lib\pdb.py", line 185, in interaction self.setup(frame, traceback) File "C:\Python25\lib\pdb.py", line 109, in setup self.stack, self.curindex = self.get_stack(f, t) File "C:\Python25\lib\bdb.py", line 318, in get_stack i = max(0, len(stack) - 1) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1592241&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1591122 ] problem building python in vs8express
Bugs item #1591122, was opened at 2006-11-05 20:31 Message generated for change (Comment added) made by thomashsouthern You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Southern (thomashsouthern) Assigned to: Nobody/Anonymous (nobody) Summary: problem building python in vs8express Initial Comment: When I tried to build pythoncore in vc++8 express, it worked without a hitch until the link stage when i got an unresolved external _init_types. Python compiles just fine and pythonw compiles up to the link where it comes accross the same error. If I am suppose to contact someone else about my issue please sent me in the wright direction. my email is [EMAIL PROTECTED] -- >Comment By: Thomas Southern (thomashsouthern) Date: 2006-11-07 17:14 Message: Logged In: YES user_id=1638546 thank you for your responses. after I answered your first question i went in search of the svn head for this project. I started at www.python.org and went to the developement area. I found svn trunk where the files for python 2.6 were located. I appolgize if I appear ignorant but I have never been interested in an open source project enough to want to compile from scratch and maybe even try and see what I could contribute. I don't know if I found the right area. where I did find. I would need to download each file individually. also, the "solution items" with "getbuildinfo.c" was not recognized by the vc++ express compiler. My question is this, am I looking in the correct location for the files I am looking for to build the source myself. also if this brings me out of the preview of the purpose of this thread please direct me to the proper location to continue to ask questions I might have as I try to understand my way around this project. thank you for your patients and help. -- Comment By: Georg Brandl (gbrandl) Date: 2006-11-07 07:41 Message: Logged In: YES user_id=849994 So could you please retry with the SVN HEAD? -- Comment By: Thomas Southern (thomashsouthern) Date: 2006-11-06 16:59 Message: Logged In: YES user_id=1638546 I am using python 2.5 -- Comment By: Georg Brandl (gbrandl) Date: 2006-11-05 23:46 Message: Logged In: YES user_id=849994 Which version of the sources are you using? I think this is fixed in the SVN HEAD. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1583946 ] SSL "issuer" and "server" names cannot be parsed
Bugs item #1583946, was opened at 2006-10-24 18:32
Message generated for change (Comment added) made by nagle
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&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
Private: No
Submitted By: John Nagle (nagle)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL "issuer" and "server" names cannot be parsed
Initial Comment:
(Python 2.5 library)
The Python SSL object offers two methods from
obtaining the info from an SSL certificate, "server()"
and "issuer()". These return strings.
The actual values in the certificate are a series
of key /value pairs in ASN.1 binary format. But what
"server()" and "issuer()" return are single strings,
with the key/value pairs separated by "/".
However, "/" is a valid character in certificate
data. So parsing such strings is ambiguous, and
potentially exploitable.
This is more than a theoretical problem. The
issuer field of Verisign certificates has a "/" in the
middle of a text field:
"/O=VeriSign Trust Network/OU=VeriSign,
Inc./OU=VeriSign International Server CA - Class
3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY
LTD.(c)97 VeriSign".
Note the
"OU=Terms of use at www.verisign.com/rpa (c)00"
with a "/" in the middle of the value field. Oops.
Worse, this is potentially exploitable. By
ordering a low-level certificate with a "/" in the
right place, you can create the illusion (at least for
flawed implementations like this one) that the
certificate belongs to someone else. Just order a
certificate from GoDaddy, enter something like this in
the "Name" field
"Myphonyname/C=US/ST=California/L=San Jose/O=eBay
Inc./OU=Site Operations/CN=signin.ebay.com"
and Python code will be spoofed into thinking you're eBay.
Fortunately, browsers don't use Python code.
The actual bug is in
python/trunk/Modules/_ssl.c
at
if ((self->server_cert =
SSL_get_peer_certificate(self->ssl))) {
X509_NAME_oneline(X509_get_subject_name(self->server_cert),
self->server, X509_NAME_MAXLEN);
X509_NAME_oneline(X509_get_issuer_name(self->server_cert),
self->issuer, X509_NAME_MAXLEN);
The "X509_name_oneline" function takes an X509_NAME
structure, which is the certificate system's
representation of a list, and flattens it into a
printable string. This is a debug function, not one
for use in production code. The SSL documentation for
"X509_name_oneline" says:
"The functions X509_NAME_oneline() and
X509_NAME_print() are legacy functions which produce a
non standard output form, they don't handle multi
character fields and have various quirks and
inconsistencies. Their use is strongly discouraged in
new applications."
What OpenSSL callers are supposed to do is call
X509_NAME_entry_count() to get the number of entries in
an X509_NAME structure, then get each entry with
X509_NAME_get_entry(). A few more calls will obtain
the name/value pair from the entry, as UTF8 strings,
which should be converted to Python UNICODE strings.
OpenSSL has all the proper support, but Python's shim
doesn't interface to it correctly.
X509_NAME_oneline() doesn't handle Unicode; it converts
non-ASCII values to "\xnn" format. Again, it's for
debug output only.
So what's needed are two new functions for Python's SSL
sockets to replace "issuer" and "server". The new
functions should return lists of Unicode strings
representing the key/value pairs. (A list is needed,
not a dictionary; two strings with the same key
are both possible and common.)
The reason this now matters is that new "high
assurance" certs, the ones that tell you how much a
site can be trusted, are now being deployed, and to use
them effectively, you need that info. Support for them
is in Internet Explorer 7, so they're going to be
widespread soon. Python needs to catch up.
And, of course, this needs to be fixed as part of
Unicode support.
John Nagle
Animats
--
>Comment By: John Nagle (nagle)
Date: 2006-11-08 07:02
Message:
Logged In: YES
user_id=5571
I've submitted a request (titled "Request: make
X509_NAME_oneline() use same formatter as
X509_NAME_print_ex()") to the OpenSSL developers to fix this
on their side. If they fix that, delimiters will be escaped
per the standard.
The OpenSSL people should also export the functionality of
getting this information
as a UTF8 string, and if they do, Python should use that
call as part of Unicode support. Keep this open pending
action on the OpenSSL side. Thanks.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-10-27 12
[ python-Bugs-1574310 ] os.popen with os.close gives error message
Bugs item #1574310, was opened at 2006-10-10 09:45
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574310&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: dtrosset (dtrosset)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.popen with os.close gives error message
Initial Comment:
Given the following code:
import os
child_stdin = os.popen("cat -", "w")
old_stdout = os.dup(1)
os.close(child_stdin.fileno())
print "foo"
os.dup2(old_stdout, 1)
os.close(old_stdout)
I got these different results depending on the version
of python I am using.
$ python2.4 -V
Python 2.4.4c0
$ python2.4 test.py
foo
close failed: [Errno 9] Bad file descriptor
$ python2.3 -V
Python 2.3.5
$ python2.3 test/new/test.py
foo
My .02$ guess is that underlying file descriptor of
child_stdin being closed, when trying to delete this
object, it tries again to close it.
--
>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-11-08 08:03
Message:
Logged In: YES
user_id=580910
IMHO this is "don't do that then" territory. You're poking around in the inside
of file objects, you have to be careful if you do that.
BTW. What are you trying to accomplish? If you set sys.stdout to child_stdin
(e.g. "import sys; sys.stdout = child_stdin"), print will write to the
pipe. If you really want to be sure that the C-level variable stdout writes to
the pipe: os.dup2(child_stdout.fileno(), 1). You can then close
child_stdout, but still have to do the 'os.dup(1)' part if you want to restore
the real stdout later on.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574310&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
