[ python-Bugs-1202493 ] RE parser too loose with {m,n} construct
Bugs item #1202493, was opened at 2005-05-15 16:59
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: RE parser too loose with {m,n} construct
Initial Comment:
This seems wrong to me:
>>> re.match("(UNIX{})", "UNIX{}").groups()
('UNIX',)
With no numbers or commas, "{}" should not be considered
special in the pattern. The docs identify three numeric
repetition possibilities: {m}, {m,} and {m,n}. There's no
description of {} meaning anything. Either the docs should
say {} implies {1,1}, {} should have no special meaning, or
an exception should be raised during compilation of the
regular expression.
--
>Comment By: Skip Montanaro (montanaro)
Date: 2005-06-02 06:16
Message:
Logged In: YES
user_id=44345
In the absence of strong technical reasons, I'd vote to do what Perl
does. I believe the assumption all along has been that most people
coming to Python who already know how to use regular expressions are
Perl programmers. It wouldn't seem to make sense to throw little land
mines in their paths. I realize that explicit is better than implicit, but
practicality beats purity.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 16:32
Message:
Logged In: YES
user_id=1188172
Okay. Attaching patch which does that.
BTW, these things are currently allowed too (treated as
literals):
"{"
"{x"
"{x}"
"{x,y}"
"{1,x}"
etc.
The patch changes that, too.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 16:07
Message:
Logged In: YES
user_id=80475
I prefer Skip's third option, raising an exception during
compilation. This is an re syntax error. Treat it the same
way that we handle similar situations with regular Python:
>>> a[]
SyntaxError: invalid syntax
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 15:30
Message:
Logged In: YES
user_id=1188172
So, should a {} raise an error, or warn like in Ruby?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 15:25
Message:
Logged In: YES
user_id=80475
IMO, the simplest rule is that braces always be considered
special. This accommodates future extensions, simplifies
the re compiler, and makes it easier to know what needs to
be escaped.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 11:54
Message:
Logged In: YES
user_id=1188172
It's interesting what other RE implementations do with this
ambiguity:
Perl treats {} as literal in REs, as Skip proposes.
Ruby does, too, but issues a warning about } being unescaped.
GNU (e)grep v2.5.1 allows a bare {} only if it is at the
start of a RE, but matches it literally then.
GNU sed v4.1.4 does never allow it.
GNU awk v3.1.4 is gracious and acts like Perl.
Attached is a patch that fixes this behaviour in the
appearing "common sense".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202493&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1212195 ] str.lower() to have an IMPORTANT NOTE or it's for magicians
Bugs item #1212195, was opened at 2005-05-31 20:56
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&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: None
Priority: 5
Submitted By: Nikos Kouremenos (nkour)
Assigned to: M.-A. Lemburg (lemburg)
Summary: str.lower() to have an IMPORTANT NOTE or it's for magicians
Initial Comment:
lower() {maybe others} should mention that if used with
string object [not unicode object] it's likely the that
encoding will change unde some locales [eg pl_PL makes
it from utf8 to latin2]!!
or this hsould be put in the beginning of the doc in
str as a general WARNING/NOTE:
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-06-02 13:48
Message:
Logged In: YES
user_id=38388
A doc-patch would be nice.
I don't like the general situation either. Unicode doesn't
behave like this and I don't think string.lower() and
.upper() should either, but there are users out there who
think differently, so we might want to add a parameter which
then allows modifying the type of mapping:
string.lower(map='ascii')
string.upper(map='latin-1')
etc.
Just an idea.
PS: I'll be offline for two weeks now, so don't expect any
more comments before then.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-01 23:43
Message:
Logged In: YES
user_id=80475
Mark, do you have any thoughts on this one?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1209880 ] doc bug in Lock.acquire
Bugs item #1209880, was opened at 2005-05-27 10:04
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209880&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: None
Priority: 5
Submitted By: Chris Perkins (cperkins)
Assigned to: Nobody/Anonymous (nobody)
Summary: doc bug in Lock.acquire
Initial Comment:
The docs for the acquire method in both the thread and
threading modules are incorrect. They describe an old
(insane) version that returned None when called with no
argument. It appears that acquire is now sane, and
always returns True or False.
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2005-06-02 08:37
Message:
Logged In: YES
user_id=11375
I think the (args==NULL) code path is vestigial and can no longer be
executed, because the PyArg_ParseTuple call will fail if args is NULL.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-05-31 05:33
Message:
Logged In: YES
user_id=1188172
It certainly seems that there is a code path in Lock.acquire
that can return None, as the following excerpt from
Modules/threadmodule.c shows:
static PyObject *
lock_PyThread_acquire_lock(lockobject *self, PyObject *args)
{
int i = 1;
if (!PyArg_ParseTuple(args, "|i:acquire", &i))
return NULL;
Py_BEGIN_ALLOW_THREADS
i = PyThread_acquire_lock(self->lock_lock, i);
Py_END_ALLOW_THREADS
if (args == NULL) {
Py_INCREF(Py_None);
return Py_None;
}
else
return PyBool_FromLong((long)i);
}
Nevertheless, a_lock.acquire() still returns true.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209880&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1213475 ] Queue.qsize() better info about unreliability
Bugs item #1213475, was opened at 2005-06-02 15:56 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=1213475&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: None Priority: 5 Submitted By: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: Queue.qsize() better info about unreliability Initial Comment: I know Queues are supposed to be used mostly in threads apps. since they are not banned to apps without threads, I think that | qsize(self) | Return the approximate size of the queue (not reliable!). can be better. You mean not reliable (or unreliable :D) because of threads right? if you mean *GENERALLY* because of when ti goes to next instruction it might have change, then put this not reliable thing in len() too ;) I propose: (urreliable if using threads) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213475&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1213475 ] Queue.qsize() better info about unreliability
Bugs item #1213475, was opened at 2005-06-02 15:56 Message generated for change (Comment added) made by nkour You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213475&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: None Priority: 5 Submitted By: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: Queue.qsize() better info about unreliability Initial Comment: I know Queues are supposed to be used mostly in threads apps. since they are not banned to apps without threads, I think that | qsize(self) | Return the approximate size of the queue (not reliable!). can be better. You mean not reliable (or unreliable :D) because of threads right? if you mean *GENERALLY* because of when ti goes to next instruction it might have change, then put this not reliable thing in len() too ;) I propose: (urreliable if using threads) -- >Comment By: Nikos Kouremenos (nkour) Date: 2005-06-02 16:02 Message: Logged In: YES user_id=865368 or better: qsize() :: "Return the approximate size of the queue. Because of multithreading semantics, this number is not reliable." (RexxFi) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213475&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1177831 ] (?(id)yes|no) only works when referencing the first group
Bugs item #1177831, was opened at 2005-04-06 11:06 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177831&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: André Malo (ndparker) >Assigned to: A.M. Kuchling (akuchling) Summary: (?(id)yes|no) only works when referencing the first group Initial Comment: (?(id)yes|no) only works when referencing the first group Referencing other marked groups may lead to weird results. The problem is, that the compiler stores the following code: ... (op = GROUPREF_EXISTS) while the matcher expects: ... where group is and is . This is the problematic code in sre_compile.py (1.57): 168 elif op is GROUPREF_EXISTS: 169 emit(OPCODES[op]) 170 emit((av[0]-1)*2) 171 skipyes = _len(code); emit(0) 172 _compile(code, av[1], flags) changing line 170 to emit(av[0]-1) fixes the bug. -- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-02 09:41 Message: Logged In: YES user_id=11375 Thank you for your excellent explanation and suggested fix. I've applied the fix to both CVS HEAD and 2.4-maint, and added a test case that exercises groups greater than 1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177831&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1193001 ] Notation
Bugs item #1193001, was opened at 2005-04-30 10:01 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193001&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mythril (mythrix) >Assigned to: A.M. Kuchling (akuchling) Summary: Notation Initial Comment: In Notation, it says the BNF form used is: name: lc_letter (lc_letter | "_")* lc_letter: "a"..."z" But in the documentation, it is: identifier ::= (letter|"_") (letter | digit | "_")* letter ::= lowercase | uppercase (ie, ::=, and not :) -- >Comment By: A.M. Kuchling (akuchling) Date: 2005-06-02 09:53 Message: Logged In: YES user_id=11375 The notation section was using a different LaTeX macro from the other grammar rules; I've fixed this on the HEAD and 2.4-maint branches. Thanks for reporting this error! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193001&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1163244 ] Syntax error on large file with MBCS encoding
Bugs item #1163244, was opened at 2005-03-14 20:20 Message generated for change (Comment added) made by nikis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: Accepted Priority: 7 Submitted By: Tim N. van der Leeuw (tnleeuw) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax error on large file with MBCS encoding Initial Comment: Large files generated by make-py.py from the win32all extensions cannot be compiled by Python2.4.1rc1 - they give a syntax error. This is a regression from 2.3.5 (With Python2.4, the interpreter crashes. That is fixed now.) Removing the mbcs encoding line from the top of the file, compilation succeeds. File should be attached, as zip-file. Probably requires win32all extensions to be installed to be compiled / imported (generated using build 203 of the win32all extensions). -- Comment By: Niki Spahiev (nikis) Date: 2005-06-02 16:11 Message: Logged In: YES user_id=27708 i have reproductable test case with encoding cp1251 file is 1594 bytes long, how to attach it? -- Comment By: Walter Dörwald (doerwalter) Date: 2005-04-14 23:40 Message: Logged In: YES user_id=89016 Importing foo2.py on Linux (with the current CVS HEAD version of Python) gives me a segmentation fault with the following stacktrace: 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 880 classname = inst->in_class->cl_name; (gdb) bt #0 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 #1 0x08082235 in PyObject_Repr (v=0xb7c158bc) at Objects/object.c:308 #2 0x080f3ccd in err_input (err=0xbfffe000) at Python/pythonrun.c:1478 #3 0x080f3956 in PyParser_SimpleParseFileFlags (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257, flags=0) at Python/pythonrun.c:1348 #4 0x080f3982 in PyParser_SimpleParseFile (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257) at Python/pythonrun.c:1355 #5 0x080e6fef in parse_source_module (pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:761 #6 0x080e72db in load_source_module (name=0xbfffe9d0 "foo2", pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:885 #7 0x080e86b4 in load_module (name=0xbfffe9d0 "foo2", fp=0x818d6e0, buf=0xbfffe530 "foo2.py", type=1, loader=0x0) at Python/import.c:1656 #8 0x080e9d52 in import_submodule (mod=0x8145768, subname=0xbfffe9d0 "foo2", fullname=0xbfffe9d0 "foo2") at Python/import.c:2250 #9 0x080e9511 in load_next (mod=0x8145768, altmod=0x8145768, p_name=0xbfffedf0, buf=0xbfffe9d0 "foo2", p_buflen=0xbfffe9cc) at Python/import.c:2070 #10 0x080e8e5e in import_module_ex (name=0x0, globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1905 #11 0x080e914b in PyImport_ImportModuleEx (name=0xb7cd8824 "foo2", globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1946 #12 0x080b5c87 in builtin___import__ (self=0x0, args=0xb7d1e634) at Python/bltinmodule.c:45 #13 0x0811d32e in PyCFunction_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/methodobject.c:73 #14 0x0805d188 in PyObject_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/abstract.c:1757 #15 0x080ca79d in PyEval_CallObjectWithKeywords (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Python/ceval.c:3425 #16 0x080c6719 in PyEval_EvalFrame (f=0x816dd7c) at Python/ceval.c:2026 #17 0x080c8fdd in PyEval_EvalCodeEx (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736 #18 0x080bffb0 in PyEval_EvalCode (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94) at Python/ceval.c:490 #19 0x080f361d in run_node (n=0xb7d122d0, filename=0x8123ba3 "", globals=0xb7d62e94, locals=0xb7d62e94, flags=0xb584) at Python/pythonrun.c:1265 #20 0x080f1f58 in PyRun_InteractiveOneFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xb584) at Python/pythonrun.c:762 #21 0x080f1c93 in PyRun_InteractiveLoopFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xb584) at Python/pythonrun.c:695 #22 0x080f1af6 in PyRun_AnyFileExFlags (fp=0xb7e94720, filename=0x8123ba3 "", closeit=0, flags=0xb584) at Python/pythonrun.c:658 #23 0x08055e45 in Py_Main (argc=1, argv=0xb634) at Modules/main.c:484 #24 0x08055366 in main (argc=1, argv=0xb634) at Modules/python.c:23 The value object in err_input() (in the E_DECODE case) seems to be bogus (it gives me a refcount of -606348325). -- Comment By: Timo Linna (t
[ python-Bugs-1209880 ] doc bug in Lock.acquire
Bugs item #1209880, was opened at 2005-05-27 10:04
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209880&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Chris Perkins (cperkins)
>Assigned to: A.M. Kuchling (akuchling)
Summary: doc bug in Lock.acquire
Initial Comment:
The docs for the acquire method in both the thread and
threading modules are incorrect. They describe an old
(insane) version that returned None when called with no
argument. It appears that acquire is now sane, and
always returns True or False.
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2005-06-02 13:01
Message:
Logged In: YES
user_id=11375
I've changed the docs on both the HEAD and 2.4-maint branches to only
describe the True/False return values. Thanks for your report!
--
Comment By: A.M. Kuchling (akuchling)
Date: 2005-06-02 08:37
Message:
Logged In: YES
user_id=11375
I think the (args==NULL) code path is vestigial and can no longer be
executed, because the PyArg_ParseTuple call will fail if args is NULL.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-05-31 05:33
Message:
Logged In: YES
user_id=1188172
It certainly seems that there is a code path in Lock.acquire
that can return None, as the following excerpt from
Modules/threadmodule.c shows:
static PyObject *
lock_PyThread_acquire_lock(lockobject *self, PyObject *args)
{
int i = 1;
if (!PyArg_ParseTuple(args, "|i:acquire", &i))
return NULL;
Py_BEGIN_ALLOW_THREADS
i = PyThread_acquire_lock(self->lock_lock, i);
Py_END_ALLOW_THREADS
if (args == NULL) {
Py_INCREF(Py_None);
return Py_None;
}
else
return PyBool_FromLong((long)i);
}
Nevertheless, a_lock.acquire() still returns true.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209880&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-1213703 ] Move test_method_checksum from test_unicodedata.
Feature Requests item #1213703, was opened at 2005-06-02 18:32 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=1213703&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: Darek Suchojad (dsuch) Assigned to: Nobody/Anonymous (nobody) Summary: Move test_method_checksum from test_unicodedata. Initial Comment: Hi, this isn't really an RFE but there's no Requests For Modifications tracker anywhere ;-) I was wondering if it would make sense to move test_method_checksum from test_unicodedata to test_unicode. This test doesn't deal with unicodedata module at all; it's surely needed and an important one but I think its location is somewhat misleading as it's not using unicodedata module, it doesn't test this module's behaviour. What do you think? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1213703&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-1213703 ] Move test_method_checksum from test_unicodedata.
Feature Requests item #1213703, was opened at 2005-06-02 20:32 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1213703&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: Darek Suchojad (dsuch) Assigned to: Nobody/Anonymous (nobody) Summary: Move test_method_checksum from test_unicodedata. Initial Comment: Hi, this isn't really an RFE but there's no Requests For Modifications tracker anywhere ;-) I was wondering if it would make sense to move test_method_checksum from test_unicodedata to test_unicode. This test doesn't deal with unicodedata module at all; it's surely needed and an important one but I think its location is somewhat misleading as it's not using unicodedata module, it doesn't test this module's behaviour. What do you think? -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-06-02 22:47 Message: Logged In: YES user_id=89016 test_unicodedata() might not use the unicodedata module, but it uses the Unicode database, so I think this is justified. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1213703&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-1213703 ] Move test_method_checksum from test_unicodedata.
Feature Requests item #1213703, was opened at 2005-06-02 18:32 Message generated for change (Comment added) made by dsuch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1213703&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: Darek Suchojad (dsuch) Assigned to: Nobody/Anonymous (nobody) Summary: Move test_method_checksum from test_unicodedata. Initial Comment: Hi, this isn't really an RFE but there's no Requests For Modifications tracker anywhere ;-) I was wondering if it would make sense to move test_method_checksum from test_unicodedata to test_unicode. This test doesn't deal with unicodedata module at all; it's surely needed and an important one but I think its location is somewhat misleading as it's not using unicodedata module, it doesn't test this module's behaviour. What do you think? -- >Comment By: Darek Suchojad (dsuch) Date: 2005-06-02 21:08 Message: Logged In: YES user_id=954779 Ah, I get it. I'm trying to port unicodedata to Jython (so far I have almost completed creating its pure-Python version which I will rewrite in Java) and that's how I've discovered this "inconsistency", but I understand your point, so I'll just withdraw my proposal, it was just a thought after all... -- Comment By: Walter Dörwald (doerwalter) Date: 2005-06-02 20:47 Message: Logged In: YES user_id=89016 test_unicodedata() might not use the unicodedata module, but it uses the Unicode database, so I think this is justified. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1213703&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1213894 ] os.path.realpath() cannot handle symlinks
Bugs item #1213894, was opened at 2005-06-02 17:33
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=1213894&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.realpath() cannot handle symlinks
Initial Comment:
To reproduce:
Create a link, say to /tmp:
bagira:~/python> ls -l xxx
lrwxrwxrwx1 ilya ilya4 2005-06-02
17:09 xxx -> /tmp/
And now:
bagira:~/python> python2.4
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
Type "help", "copyright", "credits" or "license" for
more
information.
>>> import os.path
>>> os.path.realpath("xxx")
'/home/ilya/python/xxx'
I'd expect realpath() to return "/tmp"
Note: This bug was reported earlier (e.g bug 990669)
but it was closed as fixed
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&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-1213703 ] Move test_method_checksum from test_unicodedata.
Feature Requests item #1213703, was opened at 2005-06-02 13:32 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1213703&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Darek Suchojad (dsuch) Assigned to: Nobody/Anonymous (nobody) Summary: Move test_method_checksum from test_unicodedata. Initial Comment: Hi, this isn't really an RFE but there's no Requests For Modifications tracker anywhere ;-) I was wondering if it would make sense to move test_method_checksum from test_unicodedata to test_unicode. This test doesn't deal with unicodedata module at all; it's surely needed and an important one but I think its location is somewhat misleading as it's not using unicodedata module, it doesn't test this module's behaviour. What do you think? -- Comment By: Darek Suchojad (dsuch) Date: 2005-06-02 16:08 Message: Logged In: YES user_id=954779 Ah, I get it. I'm trying to port unicodedata to Jython (so far I have almost completed creating its pure-Python version which I will rewrite in Java) and that's how I've discovered this "inconsistency", but I understand your point, so I'll just withdraw my proposal, it was just a thought after all... -- Comment By: Walter Dörwald (doerwalter) Date: 2005-06-02 15:47 Message: Logged In: YES user_id=89016 test_unicodedata() might not use the unicodedata module, but it uses the Unicode database, so I think this is justified. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1213703&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-1212169 ] Prepending Text
Feature Requests item #1212169, was opened at 2005-05-31 12:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212169&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Aaron Elbaz (flamesrock) Assigned to: Nobody/Anonymous (nobody) Summary: Prepending Text Initial Comment: Perhaps this has already been considered, but I have an idea that would make neat addition to python: Appending a string to another string can be done with += or .join(), but currently, there is no elegant way to prepend to a string. How about something like- string.prepend(list.pop(0) ? -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 19:45 Message: Logged In: YES user_id=80475 All string concatenation in Python creates a new string and leaves the original untouched. So, there are no append operations. Likewise, the can be no prepend operations. Instead, there are only a+b operations whose result can be assigned to 'a' to give the effect of an append, to 'b' to give the effect of a prepend, and to 'c' to create a new variable leaving the inputs untouched. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 13:48 Message: Logged In: YES user_id=1188172 -0. What's wrong with >>> string = something + string Also, the above conveys the notion that this is an expensive operation (when done multiple times, e.g. in a loop) better than a str method. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212169&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-1191699 ] make slices pickable
Feature Requests item #1191699, was opened at 2005-04-28 08:44 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191699&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: None Priority: 5 Submitted By: Sebastien de Menten (sdementen) >Assigned to: Raymond Hettinger (rhettinger) Summary: make slices pickable Initial Comment: As suggested by the summary, provide pickability of slices by default. Currently one has to use copy_reg module to register slices as pickables. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 19:50 Message: Logged In: YES user_id=80475 Okay, sounds reasonable. Will implement when I have time. -- Comment By: Sebastien de Menten (sdementen) Date: 2005-04-30 13:02 Message: Logged In: YES user_id=820079 Use case for pickable slices. Let A be a numeric array of size M x N. We want to consider sub-arrays in this array like A[:4, :] (the first 4 lines of the array). If we want to store both the array and the information of sub-arrays structures, we need to store slices (we can also store start/end indices of the array ... but this is call a slice so it would be better to have pickable slices). In fact, whenever one wants to write generic algorithm working on "sublist of lists" or "subarrays of arrays" or "sub-items of collection of items", it is nicer to use slice objects explicitly and so store them also explicitly. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-30 07:32 Message: Logged In: YES user_id=80475 Use cases? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191699&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-1190033 ] The array module and the buffer interface
Feature Requests item #1190033, was opened at 2005-04-26 01:59
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&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: Josiah Carlson (josiahcarlson)
Assigned to: Nobody/Anonymous (nobody)
Summary: The array module and the buffer interface
Initial Comment:
It would be terribly convenient if array objects were
willing to take any object supporting the buffer
interface as initialization or extension via
a.fromstring().
They currently offer the buffer interface for other
objects to read/write once the array has been created,
but they do not accept buffers during creation or
extension (except for the typecode 'c').
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-02 20:12
Message:
Logged In: YES
user_id=80475
+0 It is not unreasonable to want to generalize the
interface. OTOH, the str() workaround is trivial and explicit:
>>> buf = buffer('abcdefghi', 1, 5)
>>> array('b', str(buf))
array('b', [98, 99, 100, 101, 102])
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-04-28 07:39
Message:
Logged In: YES
user_id=341410
I couldn't sleep, so I started working on it.
Note: a.fromstring(buf_obj) works in Python 2.3 and 2.4, it
just isn't documented, nor is it exposed via array_new.
I've got less than 20 lines of changes that seem to be
necessary for array(typecode, buf) to be supported,
including documentation and unittest updates. I'll sleep on
it (I'm getting tired) and upload it tomorrow.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-04-28 01:37
Message:
Logged In: YES
user_id=341410
Not right now, but I could probably have one for you
tomorrow. You want doc updates and tests too?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-28 00:20
Message:
Logged In: YES
user_id=80475
Do you have a patch?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1185383 ] Make bisect.* functions accept an optional compare function
Feature Requests item #1185383, was opened at 2005-04-18 14:26 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1185383&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marcin Ciura (mciura) Assigned to: Nobody/Anonymous (nobody) Summary: Make bisect.* functions accept an optional compare function Initial Comment: The usability of bisect.bisect_right, bisect.bisect_left, bisect.insort_right and bisect.insort_left would increase if they accepted an optional less_than function to compare the keys. Here is my use case: I have a sorted list of reversed words and a parallel list of flags associated with these words (taken from ispell). The list of reversed words is the one searched; the flags are the result of a search. Issue #1: Now I cannot use simply a list of tuples (rev_word,flags) and a custom less_than function that compares only the first elements of two tuples. Issue #2: When a word is not found in the list, I'd like to make an educated guess as to its flags (this makes more sense in non-English languages, where e.g. infinitives have a special ending), using bisect_left and bisect_right: from bisect import * less_than = lambda x,y: x[:3]Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 20:25 Message: Logged In: YES user_id=80475 Overall, I'm -1 on this RFE. The comparison to nsmallest() and nlargest() is inaccurate. They run start-to-finish in one function call. The other heapq methods do not use key functions because they have to leave the original data structure unmolested between calls; hence, there is no ability to limit the key function calls to one per record. Likewise, with this request, the key function calls get wasted. The sort() method calls key() for every record and tosses the result afterwards. Each subsequect call to bisect() would need to repeat those calls for a log(N) subset of the data. Hence, accepting this request would create an API that encourages a wasteful design. -- Comment By: Jonas Kölker (jonaskoelker) Date: 2005-04-28 15:13 Message: Logged In: YES user_id=1153395 In a similar vein, I'd like to see that a `key' keyword argument was added to bisect.* (and perhaps `reversed' too)--it's really annoying to sort something by (not __lt__) and not be able to bsearch it. It got added to min/max and heapq.n(smallest|largest) in 2.5 fwiw ;) -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-18 15:09 Message: Logged In: YES user_id=80475 A few thoughts: * If bisect provided an optional lt argument, it would still not be thread-safe. The code for the lt function can call arbitrary Python code that runs through the eval-loop and is hence subject to a thread-switch. * An advantage of the class wrapper approach is that the prefix function gets computed just once per word. This is not a big deal for the specific case of [:3], but it could be a significant benefit for other functions that are expensive to compute (because repeated calls to bisect will access the lt function more than once). * My own approach to the particular use case would be to map prefixes to a list of revwords or (revword, flag) pairs: d = dict(abb=['abbc'], abc=['abcaa', 'abcdd', 'abcss'], abd=['abdf']) This gives O(1) lookup time and limits the calls to the prefix function to once per word. Will leave this request open as it may yet be a good idea. My concern is that it will clutter the code and the API for only a small benefit. Also, I'm looking at a more general purpose solution that would make this feature request moot. This idea is to create a fast comparison decorator class used like this: dwordlist = map(ComparisonDecorator(lambda x: x[:3]), wordlist) lp = bisect_left(dwordlist, given_rev_word) rp = bisect_right(dwordlist, given_rev_word) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1185383&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-1182143 ] making builtin exceptions more informative
Feature Requests item #1182143, was opened at 2005-04-13 06:02
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1182143&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: Sebastien de Menten (sdementen)
Assigned to: Nobody/Anonymous (nobody)
Summary: making builtin exceptions more informative
Initial Comment:
Using builtin exception information is tricky as it
consists of:
a) the type of exception (easily accessible)
b) the args attribute = a 1 element tuple with a string
1st example:
try:
print foo
except NameError, e:
print e.args
symbol = e.args[0][17:-16]
print symbols
==>
("NameError: name 'foo' is not defined", )
foo
It would be nicer to have:
e.args = ("NameError: name 'foo' is not defined", "foo")
The first element being the current string for backward
compatibilty.
=
2nd example:
try:
(4).foo
except NameError, e:
print e.args
==> ("'int' object has no attribute 'foo'",)
It would be nicer to have:
e.args = ("'int' object has no attribute 'foo'", 4, "foo")
Again, the first element being the current string for
backward compatibilty.
=
Moreover, in the documentation about Exception, I read
"""Warning: Messages to exceptions are not part of the
Python API. Their
contents may change from one version of Python to the
next without warning
and should not be relied on by code which will run under
multiple versions
of the interpreter. """
So even args could not be relied upon !
But it also means that there is no need to be backward
compatible (I am playing devil's advocate, backward
compatibility is important !)
Seb
ps: There may be problems (that I am not aware) with
a) an exception keeping references to other objects
b) C API that can throw only exceptions with strings
c) a specific advantage of having strings only in builtin
exceptions
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-02 20:33
Message:
Logged In: YES
user_id=80475
This looks like a good idea to me.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1182143&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-1163139 ] expm1 and log1p
Feature Requests item #1163139, was opened at 2005-03-14 12:24 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: expm1 and log1p Initial Comment: Could we please have expm1 and log1p interfaced in the math module (where these exist in libm)? These are essential for any serious mathematical applications. lgamma would be nice too. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-02 20:34 Message: Logged In: YES user_id=80475 For the reasons mentioned by Tim, closing this RFE. -- Comment By: Tim Peters (tim_one) Date: 2005-03-14 13:20 Message: Logged In: YES user_id=31435 Python code intends to be portable, and the math module hasn't yet included any platform-specific functions. I used to write math libraries for a living, so I know about netlib . If that's the intended approach to portability , it still needs someone to volunteer to do all the non-trivial coding, testing, doc, license-hassling, and x-platform config work. Won't be me because I can't make time for it. Note that you could easily write an extension module exposing these functions on _your_ platform (assuming your platform C supplies them). -- Comment By: Keith Briggs (kbriggs) Date: 2005-03-14 12:59 Message: Logged In: YES user_id=888261 Is there an objection in principle to including something in the math module only if it is found in the system's libm? If so, a solution would be to use a C implementation of expm1 when it is not already supplied, for example from fdlibm: http://www.netlib.org/fdlibm/ -- Comment By: Tim Peters (tim_one) Date: 2005-03-14 12:39 Message: Logged In: YES user_id=31435 Hard one, since none of those functions are required by the C89 standard, Python doesn't require more than C89, and the math module overwhelmingly consists of thin wrappers around the platform C's implementations. When C99 is universally available, then it will be easy. Before then, someone would have to volunteer non-trivial work (for example, Microsoft's C runtime doesn't supply any of these -- it's a x-platform mess). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1163139&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1161031 ] Neverending warnings from asyncore
Bugs item #1161031, was opened at 2005-03-11 13:34 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. -- >Comment By: Tony Meyer (anadelonbrin) Date: 2005-06-03 13:38 Message: Logged In: YES user_id=552329 I am not at all unwilling (and this isn't a problem for me personally - the issue here is whether this is good for Python in general) to subclass. Deciding to subclass does *not* mean that you should have to replace all functions in the parent class. If you did, then there would be little point in subclassing at all. Sensible default behaviour should be provided as methods of classes. The current behaviour of the handle_expt() method is not sensible. It essentially forces the user to override that method, even if they have no interest in handling errors (e.g. and would normally just override handle_read and handle_write). This is *not* rare. You haven't seen any in years, because this was a change introduced in Python 2.4, which hasn't been released for even one year yet. I agree that the desired behaviour will be application specific. But what is the point of having default behaviour that will essentially crash the program/system running it? Having default behaviour be "pass" would be more useful. At the very least, this is a problem that many people (compared to the number that will use asyncore) will come across and should be reflected as such in the documentation. If you haven't replicated this problem on your system so that you understand it, please do. I am happy to provide a simple script to demonstrate, if necessary. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-01 07:34 Message: Logged In: YES user_id=341410 You seem to be unwilling to subclass asyncore.dispatcher to extend its functionality, and the only reason you have given as to why you are unwilling is "As much as possible a class should provide sensible methods, so that overriding is kept to a minimum." (I personally subclass dispatcher and its async_chat derivative qutie often) Now, in the case of the other standard socket server and client framework in the Python standard library, namely the SocketServer module and its derivatives, you will find extending the functionality of those classes is via subclassing and overriding methods as necessary. To me, when tw
[ python-Bugs-1161031 ] Neverending warnings from asyncore
Bugs item #1161031, was opened at 2005-03-10 19:34 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) >Assigned to: A.M. Kuchling (akuchling) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. -- >Comment By: Tim Peters (tim_one) Date: 2005-06-02 22:02 Message: Logged In: YES user_id=31435 I agree the change in default behavior here was at least questionable, and spent more than a week of my own "dealing with consequences" of 2.4 asyncore changes in ZODB and Zope. Assigning to Andrew, since it looks like he made the change in question here. Andrew, why did this change? How can it be improved? I don't think Tony has mentioned it here, but when SpamBayes was first released with Python 2.4, it was a disaster because some users found their hard drives literally filled with gigabytes of mysterious "warning: unhandled exception" messages. -- Comment By: Tony Meyer (anadelonbrin) Date: 2005-06-02 21:38 Message: Logged In: YES user_id=552329 I am not at all unwilling (and this isn't a problem for me personally - the issue here is whether this is good for Python in general) to subclass. Deciding to subclass does *not* mean that you should have to replace all functions in the parent class. If you did, then there would be little point in subclassing at all. Sensible default behaviour should be provided as methods of classes. The current behaviour of the handle_expt() method is not sensible. It essentially forces the user to override that method, even if they have no interest in handling errors (e.g. and would normally just override handle_read and handle_write). This is *not* rare. You haven't seen any in years, because this was a change introduced in Python 2.4, which hasn't been released for even one year yet. I agree that the desired behaviour will be application specific. But what is the point of having default behaviour that will essentially crash the program/system running it? Having default behaviour be "pass" would be more useful. At the very least, this is a problem that many people (compared to the number that will use asyncore) will come across and should be reflected as such in the documentation. If you haven't replicated this problem on your system so that you understand it, please do. I am happy to provide a simple script to demonstrate, if necessary. -
[ python-Feature Requests-1190033 ] The array module and the buffer interface
Feature Requests item #1190033, was opened at 2005-04-25 23:59
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&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: Josiah Carlson (josiahcarlson)
Assigned to: Nobody/Anonymous (nobody)
Summary: The array module and the buffer interface
Initial Comment:
It would be terribly convenient if array objects were
willing to take any object supporting the buffer
interface as initialization or extension via
a.fromstring().
They currently offer the buffer interface for other
objects to read/write once the array has been created,
but they do not accept buffers during creation or
extension (except for the typecode 'c').
--
>Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-06-02 19:04
Message:
Logged In: YES
user_id=341410
I had assumed str(buf) copied the contents of the buffer,
but I was mistaken (read the source Josiah).
As I stated in my previous post, array.fromstring takes
buffer objects, so the documentation should be updated in
that case, which I can do if desired.
Honestly, I am also +0 on the patch. I think it is
convenient for completeness sake, but with array.fromstring,
and str(buf) being fast, it isn't necessary.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-02 18:12
Message:
Logged In: YES
user_id=80475
+0 It is not unreasonable to want to generalize the
interface. OTOH, the str() workaround is trivial and explicit:
>>> buf = buffer('abcdefghi', 1, 5)
>>> array('b', str(buf))
array('b', [98, 99, 100, 101, 102])
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-04-28 05:39
Message:
Logged In: YES
user_id=341410
I couldn't sleep, so I started working on it.
Note: a.fromstring(buf_obj) works in Python 2.3 and 2.4, it
just isn't documented, nor is it exposed via array_new.
I've got less than 20 lines of changes that seem to be
necessary for array(typecode, buf) to be supported,
including documentation and unittest updates. I'll sleep on
it (I'm getting tired) and upload it tomorrow.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-04-27 23:37
Message:
Logged In: YES
user_id=341410
Not right now, but I could probably have one for you
tomorrow. You want doc updates and tests too?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-27 22:20
Message:
Logged In: YES
user_id=80475
Do you have a patch?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&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-1182143 ] making builtin exceptions more informative
Feature Requests item #1182143, was opened at 2005-04-13 13:02
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1182143&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: Sebastien de Menten (sdementen)
Assigned to: Nobody/Anonymous (nobody)
Summary: making builtin exceptions more informative
Initial Comment:
Using builtin exception information is tricky as it
consists of:
a) the type of exception (easily accessible)
b) the args attribute = a 1 element tuple with a string
1st example:
try:
print foo
except NameError, e:
print e.args
symbol = e.args[0][17:-16]
print symbols
==>
("NameError: name 'foo' is not defined", )
foo
It would be nicer to have:
e.args = ("NameError: name 'foo' is not defined", "foo")
The first element being the current string for backward
compatibilty.
=
2nd example:
try:
(4).foo
except NameError, e:
print e.args
==> ("'int' object has no attribute 'foo'",)
It would be nicer to have:
e.args = ("'int' object has no attribute 'foo'", 4, "foo")
Again, the first element being the current string for
backward compatibilty.
=
Moreover, in the documentation about Exception, I read
"""Warning: Messages to exceptions are not part of the
Python API. Their
contents may change from one version of Python to the
next without warning
and should not be relied on by code which will run under
multiple versions
of the interpreter. """
So even args could not be relied upon !
But it also means that there is no need to be backward
compatible (I am playing devil's advocate, backward
compatibility is important !)
Seb
ps: There may be problems (that I am not aware) with
a) an exception keeping references to other objects
b) C API that can throw only exceptions with strings
c) a specific advantage of having strings only in builtin
exceptions
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2005-06-03 08:03
Message:
Logged In: YES
user_id=89016
+1
This should probably be part of Brett's Py3000 exception PEP.
Candidates I can think of are:
KeyError(obj=..., key=...)
IndexError(obj=..., index=...)
IOError(file=..., code=...)
NameError(name=...)
Regenerating the message would be done with __str__().
I'm not sure how this would work on the level of the C API.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-03 03:33
Message:
Logged In: YES
user_id=80475
This looks like a good idea to me.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1182143&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-1190033 ] The array module and the buffer interface
Feature Requests item #1190033, was opened at 2005-04-26 01:59
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&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: Josiah Carlson (josiahcarlson)
Assigned to: Nobody/Anonymous (nobody)
Summary: The array module and the buffer interface
Initial Comment:
It would be terribly convenient if array objects were
willing to take any object supporting the buffer
interface as initialization or extension via
a.fromstring().
They currently offer the buffer interface for other
objects to read/write once the array has been created,
but they do not accept buffers during creation or
extension (except for the typecode 'c').
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-03 01:42
Message:
Logged In: YES
user_id=80475
I recommend dropping this one and leaving the API alone.
The improvement would be so small that it isn't worth the
time to review it, test it, and introduce another version
incompatability (something that runs on Py2.5 that won't run
on Py2.4).
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-06-02 21:04
Message:
Logged In: YES
user_id=341410
I had assumed str(buf) copied the contents of the buffer,
but I was mistaken (read the source Josiah).
As I stated in my previous post, array.fromstring takes
buffer objects, so the documentation should be updated in
that case, which I can do if desired.
Honestly, I am also +0 on the patch. I think it is
convenient for completeness sake, but with array.fromstring,
and str(buf) being fast, it isn't necessary.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-02 20:12
Message:
Logged In: YES
user_id=80475
+0 It is not unreasonable to want to generalize the
interface. OTOH, the str() workaround is trivial and explicit:
>>> buf = buffer('abcdefghi', 1, 5)
>>> array('b', str(buf))
array('b', [98, 99, 100, 101, 102])
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-04-28 07:39
Message:
Logged In: YES
user_id=341410
I couldn't sleep, so I started working on it.
Note: a.fromstring(buf_obj) works in Python 2.3 and 2.4, it
just isn't documented, nor is it exposed via array_new.
I've got less than 20 lines of changes that seem to be
necessary for array(typecode, buf) to be supported,
including documentation and unittest updates. I'll sleep on
it (I'm getting tired) and upload it tomorrow.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-04-28 01:37
Message:
Logged In: YES
user_id=341410
Not right now, but I could probably have one for you
tomorrow. You want doc updates and tests too?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-28 00:20
Message:
Logged In: YES
user_id=80475
Do you have a patch?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&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-1190033 ] The array module and the buffer interface
Feature Requests item #1190033, was opened at 2005-04-25 23:59
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&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: Josiah Carlson (josiahcarlson)
Assigned to: Nobody/Anonymous (nobody)
Summary: The array module and the buffer interface
Initial Comment:
It would be terribly convenient if array objects were
willing to take any object supporting the buffer
interface as initialization or extension via
a.fromstring().
They currently offer the buffer interface for other
objects to read/write once the array has been created,
but they do not accept buffers during creation or
extension (except for the typecode 'c').
--
>Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-06-02 23:50
Message:
Logged In: YES
user_id=341410
Sounds reasonable.
What about updating the documentation for array.fromstring()
to acknowledge that it accepts buffer objects, or do we call
it an 'undocumented and untested bonus feature'?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-02 23:42
Message:
Logged In: YES
user_id=80475
I recommend dropping this one and leaving the API alone.
The improvement would be so small that it isn't worth the
time to review it, test it, and introduce another version
incompatability (something that runs on Py2.5 that won't run
on Py2.4).
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-06-02 19:04
Message:
Logged In: YES
user_id=341410
I had assumed str(buf) copied the contents of the buffer,
but I was mistaken (read the source Josiah).
As I stated in my previous post, array.fromstring takes
buffer objects, so the documentation should be updated in
that case, which I can do if desired.
Honestly, I am also +0 on the patch. I think it is
convenient for completeness sake, but with array.fromstring,
and str(buf) being fast, it isn't necessary.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-02 18:12
Message:
Logged In: YES
user_id=80475
+0 It is not unreasonable to want to generalize the
interface. OTOH, the str() workaround is trivial and explicit:
>>> buf = buffer('abcdefghi', 1, 5)
>>> array('b', str(buf))
array('b', [98, 99, 100, 101, 102])
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-04-28 05:39
Message:
Logged In: YES
user_id=341410
I couldn't sleep, so I started working on it.
Note: a.fromstring(buf_obj) works in Python 2.3 and 2.4, it
just isn't documented, nor is it exposed via array_new.
I've got less than 20 lines of changes that seem to be
necessary for array(typecode, buf) to be supported,
including documentation and unittest updates. I'll sleep on
it (I'm getting tired) and upload it tomorrow.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-04-27 23:37
Message:
Logged In: YES
user_id=341410
Not right now, but I could probably have one for you
tomorrow. You want doc updates and tests too?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-27 22:20
Message:
Logged In: YES
user_id=80475
Do you have a patch?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190033&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
