[ python-Bugs-793764 ] pyconfig.h defines _POSIX_C_SOURCE, conflicting with feature
Bugs item #793764, was opened at 2003-08-23 16:19 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793764&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: Installation Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: pyconfig.h defines _POSIX_C_SOURCE, conflicting with feature Initial Comment: [forwarded from http://bugs.debian.org/206805] the installed include/python2.3/pyconfig.h defines _POSIX_C_SOURCE, which leaks down into packages built against python-2.3. AFAIK, _POSIX_C_SOURCE is reserved for use by the C library, and is of course defined in /usr/include/features.h. Example excerpt from a build log: In file included from /usr/include/python2.3/Python.h:8, from sg_config.h:22, from sg.h:29, from sg_project_autosave.c:26: /usr/include/python2.3/pyconfig.h:844:1: Warnung: "_POSIX_C_SOURCE" redefined In file included from /usr/include/stdlib.h:25, from sg_project_autosave.c:19: /usr/include/features.h:171:1: Warnung: this is the location of the previous definition -- >Comment By: Matthias Klose (doko) Date: 2007-01-11 10:13 Message: Logged In: YES user_id=60903 Originator: YES 8. For the C programming language, shall define _POSIX_C_SOURCE to be 200112L before any header is included _POSIX_C_SOURCE should be defined "before any header is included". That phrase was taken from the following comments: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793764&group_id=5470 It's described at: Single Unix Specification 3: "2.2.1 Strictly Conforming POSIX Application" 8. -- Comment By: Martin v. Löwis (loewis) Date: 2003-08-31 19:26 Message: Logged In: YES user_id=21627 _POSIX_C_SOURCE is not reserved for the C library, but for the application, see http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html (section "Strictly Conforming POSIX Application") A conforming POSIX application *must* define _POSIX_C_SOURCE, so if your C library also defines it, it is a bug in the C library. Most likely, the author failed to include Python.h before other system headers, as required per http://www.python.org/doc/current/api/includes.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793764&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1632328 ] logging.config.fileConfig doesn't clear logging._handlerList
Bugs item #1632328, was opened at 2007-01-10 12:56 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1632328&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: Stefan H. Holek (shh42) >Assigned to: Vinay Sajip (vsajip) Summary: logging.config.fileConfig doesn't clear logging._handlerList Initial Comment: logging.config.fileConfig resets logging._handlers but not logging._handlerList, resulting in tracebacks on shutdown. e.g. Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/local/python2.4/lib/python2.4/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/python2.4/lib/python2.4/logging/__init__.py", line 1333, in shutdown h.close() File "/usr/local/python2.4/lib/python2.4/logging/__init__.py", line 674, in close del _handlers[self] KeyError: AFAICT this is fixed in Python 2.5 but has not been backported. Zope cannot use 2.5 as of yet. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-01-11 12:27 Message: Logged In: YES user_id=849994 Originator: NO Does a backport to 2.4 make sense? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1632328&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-1627266 ] optparse "store" action should not gobble up next option
Feature Requests item #1627266, was opened at 2007-01-03 11:46
Message generated for change (Comment added) made by bediviere
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1627266&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: Raghuram Devarakonda (draghuram)
Assigned to: Greg Ward (gward)
Summary: optparse "store" action should not gobble up next option
Initial Comment:
Hi,
Check the following code:
--opttest.py--
from optparse import OptionParser
def process_options():
global options, args, parser
parser = OptionParser()
parser.add_option("--test", action="store_true")
parser.add_option("-m", metavar="COMMENT", dest="comment", default=None)
(options, args) = parser.parse_args()
return
process_options()
print "comment (%r)" % options.comment
-
$ ./opttest.py -m --test
comment ('--test')
I was expecting this to give an error as "--test" is an option. But it looks
like even C library's getopt() behaves similarly. It will be nice if optparse
can report error in this case.
--
Comment By: Steven Bethard (bediviere)
Date: 2007-01-11 08:41
Message:
Logged In: YES
user_id=945502
Originator: NO
For what it's worth, argparse_ gives an error here:
>>> parser = argparse.ArgumentParser(prog='PROG')
>>> parser.add_argument('--test', action='store_true')
>>> parser.add_argument('-m', dest='comment')
>>> parser.parse_args(['-m', '--test'])
usage: PROG [-h] [--test] [-m COMMENT]
PROG: error: argument -m: expected one argument
That's because argparse assumes that anything that looks like "--foo" is
an option (unless it's after the pseudo-argument "--" on the command
line).
.. _argparse: http://argparse.python-hosting.com/
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-01-05 10:58
Message:
Logged In: YES
user_id=984087
Originator: YES
It is possible to deduce "--test" as an option because it is in the list
of options given to optparse. But your point about what if the user really
wants "--test" as an option argument is valid. I guess this request can be
closed.
Thanks,
Raghu.
--
Comment By: David Goodger (goodger)
Date: 2007-01-05 09:28
Message:
Logged In: YES
user_id=7733
Originator: NO
I think what you're asking for is ambiguous at best. In your example, how
could optparse possibly decide that the "--test" is a second option, not an
option argument? What if you *do* want "--test" as an argument?
Assigning to Greg Ward. Recommend closing as invalid.
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-01-05 08:19
Message:
Logged In: YES
user_id=984087
Originator: YES
I am attaching the code fragment as a file since the indentation got all
messed up in the original post.
File Added: opttest.py
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1627266&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-1627266 ] optparse "store" action should not gobble up next option
Feature Requests item #1627266, was opened at 2007-01-03 18:46
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1627266&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: Raghuram Devarakonda (draghuram)
Assigned to: Greg Ward (gward)
Summary: optparse "store" action should not gobble up next option
Initial Comment:
Hi,
Check the following code:
--opttest.py--
from optparse import OptionParser
def process_options():
global options, args, parser
parser = OptionParser()
parser.add_option("--test", action="store_true")
parser.add_option("-m", metavar="COMMENT", dest="comment", default=None)
(options, args) = parser.parse_args()
return
process_options()
print "comment (%r)" % options.comment
-
$ ./opttest.py -m --test
comment ('--test')
I was expecting this to give an error as "--test" is an option. But it looks
like even C library's getopt() behaves similarly. It will be nice if optparse
can report error in this case.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-01-11 16:16
Message:
Logged In: YES
user_id=849994
Originator: NO
So how does one give option arguments starting with - to argparse?
--
Comment By: Steven Bethard (bediviere)
Date: 2007-01-11 15:41
Message:
Logged In: YES
user_id=945502
Originator: NO
For what it's worth, argparse_ gives an error here:
>>> parser = argparse.ArgumentParser(prog='PROG')
>>> parser.add_argument('--test', action='store_true')
>>> parser.add_argument('-m', dest='comment')
>>> parser.parse_args(['-m', '--test'])
usage: PROG [-h] [--test] [-m COMMENT]
PROG: error: argument -m: expected one argument
That's because argparse assumes that anything that looks like "--foo" is
an option (unless it's after the pseudo-argument "--" on the command
line).
.. _argparse: http://argparse.python-hosting.com/
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-01-05 17:58
Message:
Logged In: YES
user_id=984087
Originator: YES
It is possible to deduce "--test" as an option because it is in the list
of options given to optparse. But your point about what if the user really
wants "--test" as an option argument is valid. I guess this request can be
closed.
Thanks,
Raghu.
--
Comment By: David Goodger (goodger)
Date: 2007-01-05 16:28
Message:
Logged In: YES
user_id=7733
Originator: NO
I think what you're asking for is ambiguous at best. In your example, how
could optparse possibly decide that the "--test" is a second option, not an
option argument? What if you *do* want "--test" as an argument?
Assigning to Greg Ward. Recommend closing as invalid.
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-01-05 15:19
Message:
Logged In: YES
user_id=984087
Originator: YES
I am attaching the code fragment as a file since the indentation got all
messed up in the original post.
File Added: opttest.py
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1627266&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1504333 ] sgmllib should allow angle brackets in quoted values
Bugs item #1504333, was opened at 2006-06-11 08:58
Message generated for change (Comment added) made by haepal
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504333&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: Sam Ruby (rubys)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib should allow angle brackets in quoted values
Initial Comment:
Real live example (search for "othercorrections")
http://latticeqcd.blogspot.com/2006/05/non-relativistic-qcd.html
This addresses the following (included in the file):
# XXX The following should skip matching quotes (' or ")
--
Comment By: Haejoong Lee (haepal)
Date: 2007-01-11 13:01
Message:
Logged In: YES
user_id=135609
Originator: NO
Could someone check if the following patch fixes the problem?
This patch was made against revision 51854.
--- sgmllib.py.org 2006-11-06 02:31:12.0 -0500
+++ sgmllib.py 2007-01-11 12:39:30.0 -0500
@@ -16,6 +16,35 @@
# Regular expressions used for parsing
+class MyMatch:
+def __init__(self, i):
+self._i = i
+def start(self, i):
+return self._i
+
+class EndBracket:
+def search(self, data, index):
+s = data[index:]
+bs = None
+quote = None
+for i,c in enumerate(s):
+if bs:
+bs = False
+else:
+if c == '<' or c == '>':
+if quote is None:
+break
+elif c == "'" or c == '"':
+if c == quote:
+quote = None
+else:
+quote = c
+elif c == '\\':
+bs = True
+else:
+return None
+return MyMatch(i+index)
+
interesting = re.compile('[&<]')
incomplete = re.compile('&([a-zA-Z][a-zA-Z0-9]*|#[0-9]*)?|'
'<([a-zA-Z][^<>]*|'
@@ -29,7 +58,8 @@
shorttagopen = re.compile('<[a-zA-Z][-.a-zA-Z0-9]*/')
shorttag = re.compile('<([a-zA-Z][-.a-zA-Z0-9]*)/([^/]*)/')
piclose = re.compile('>')
-endbracket = re.compile('[<>]')
+#endbracket = re.compile('[<>]')
+endbracket = EndBracket()
tagfind = re.compile('[a-zA-Z][-_.a-zA-Z0-9]*')
attrfind = re.compile(
r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=\s*'
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-11 00:26
Message:
Logged In: YES
user_id=33168
I reverted the patch and added the test case for sgml so the
infinite loop doesn't recur. This was mentioned several
times on python-dev.
Committed revision 51854. (head)
Committed revision 51850. (2.5)
Committed revision 51853. (2.4)
--
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-06-29 13:17
Message:
Logged In: YES
user_id=3066
I checked in a modified version of this patch: changed to
use separate REs for start and end tags to reduce matching
cost for end tags; extended tests; updated to avoid breaking
previous changes to support IPv6 addresses in unquoted
attribute values.
Committed as revisions 47154 (trunk) and 47155
(release24-maint).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504333&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-1627266 ] optparse "store" action should not gobble up next option
Feature Requests item #1627266, was opened at 2007-01-03 11:46
Message generated for change (Comment added) made by bediviere
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1627266&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: Raghuram Devarakonda (draghuram)
Assigned to: Greg Ward (gward)
Summary: optparse "store" action should not gobble up next option
Initial Comment:
Hi,
Check the following code:
--opttest.py--
from optparse import OptionParser
def process_options():
global options, args, parser
parser = OptionParser()
parser.add_option("--test", action="store_true")
parser.add_option("-m", metavar="COMMENT", dest="comment", default=None)
(options, args) = parser.parse_args()
return
process_options()
print "comment (%r)" % options.comment
-
$ ./opttest.py -m --test
comment ('--test')
I was expecting this to give an error as "--test" is an option. But it looks
like even C library's getopt() behaves similarly. It will be nice if optparse
can report error in this case.
--
Comment By: Steven Bethard (bediviere)
Date: 2007-01-11 11:19
Message:
Logged In: YES
user_id=945502
Originator: NO
At the moment, you generally can't:
http://argparse.python-hosting.com/ticket/25
though the simple value "-" is valid. I do plan to address this in the
not-so-distant future (though no one yet has complained about it).
For optparse module, I think the OP's problem could likely be fixed by
editing _process_long_opt() and _process_short_opts() to do some checks
around the code:
elif nargs == 1:
value = rargs.pop(0)
else:
value = tuple(rargs[0:nargs])
del rargs[0:nargs]
You could make sure that the option arguments (the "value" objects in the
code above) were not already existing options with a check like:
all(not self._match_long_opt(arg) and
not self._short_opt.get(arg)
for arg in rargs[0:nargs])
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-01-11 09:16
Message:
Logged In: YES
user_id=849994
Originator: NO
So how does one give option arguments starting with - to argparse?
--
Comment By: Steven Bethard (bediviere)
Date: 2007-01-11 08:41
Message:
Logged In: YES
user_id=945502
Originator: NO
For what it's worth, argparse_ gives an error here:
>>> parser = argparse.ArgumentParser(prog='PROG')
>>> parser.add_argument('--test', action='store_true')
>>> parser.add_argument('-m', dest='comment')
>>> parser.parse_args(['-m', '--test'])
usage: PROG [-h] [--test] [-m COMMENT]
PROG: error: argument -m: expected one argument
That's because argparse assumes that anything that looks like "--foo" is
an option (unless it's after the pseudo-argument "--" on the command
line).
.. _argparse: http://argparse.python-hosting.com/
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-01-05 10:58
Message:
Logged In: YES
user_id=984087
Originator: YES
It is possible to deduce "--test" as an option because it is in the list
of options given to optparse. But your point about what if the user really
wants "--test" as an option argument is valid. I guess this request can be
closed.
Thanks,
Raghu.
--
Comment By: David Goodger (goodger)
Date: 2007-01-05 09:28
Message:
Logged In: YES
user_id=7733
Originator: NO
I think what you're asking for is ambiguous at best. In your example, how
could optparse possibly decide that the "--test" is a second option, not an
option argument? What if you *do* want "--test" as an argument?
Assigning to Greg Ward. Recommend closing as invalid.
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-01-05 08:19
Message:
Logged In: YES
user_id=984087
Originator: YES
I am attaching the code fragment as a file since the indentation got all
messed up in the original post.
File Added: opttest.py
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1627266&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1486663 ] Over-zealous keyword-arguments check for built-in set class
Bugs item #1486663, was opened at 2006-05-11 11:17
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 7
Private: No
Submitted By: dib (dib_at_work)
>Assigned to: Georg Brandl (gbrandl)
Summary: Over-zealous keyword-arguments check for built-in set class
Initial Comment:
The fix for bug #1119418 (xrange() builtin accepts
keyword arg silently) included in Python 2.4.2c1+
breaks code that passes keyword argument(s) into
classes derived from the built-in set class, even if
those derived classes explictly accept those keyword
arguments and avoid passing them down to the built-in
base class.
Simplified version of code in attached
BuiltinSetKeywordArgumentsCheckBroken.py fails at (G)
due to bug #1119418 if version < 2.4.2c1; if version >=
2.4.2c1 (G) passes thanks to that bug fix, but instead
(H) incorrectly-in-my-view fails.
[Presume similar cases would fail for xrange and the
other classes mentioned in #1119418.]
-- David Bruce
(Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.)
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 13:30
Message:
Logged In: YES
user_id=80475
Originator: NO
I fixed setobject.c in revisions 53380 and 53381.
Please apply similar fixes to all the other places being bitten my the
pervasive NoKeywords tests.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-10 19:49
Message:
Logged In: YES
user_id=80475
Originator: NO
My proposed solution:
- if(!PyArg_NoKeywords("set()", kwds)
+ if(type == &PySet_Type && !PyArg_NoKeywords("set()", kwds)
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-01-10 16:30
Message:
Logged In: YES
user_id=849994
Originator: NO
I'll do that, only in set_init, you have
if (!PyArg_UnpackTuple(args, self->ob_type->tp_name, 0, 1, &iterable))
Changing this to use PyArg_ParseTupleAndKeywords would require a format
string of
"|O:" + self->ob_type->tp_name
Is it worth constructing that string each time set_init() is called or
should it just be "|O:set" for
sets and frozensets?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-05 21:26
Message:
Logged In: YES
user_id=80475
Originator: NO
I prefer the approach used by list().
--
Comment By: Žiga Seilnacht (zseil)
Date: 2006-05-19 20:19
Message:
Logged In: YES
user_id=1326842
See patch #1491939
--
Comment By: Žiga Seilnacht (zseil)
Date: 2006-05-19 15:02
Message:
Logged In: YES
user_id=1326842
This bug was introduced as part of the fix for bug #1119418.
It also affects collections.deque.
Can't the _PyArg_NoKeywords check simply be moved
to set_init and deque_init as it was done for
zipimport.zipimporter?
array.array doesn't need to be changed, since it
already does all of its initialization in its
__new__ method.
The rest of the types changed in that fix should not
be affected, since they are immutable.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-05-11 12:23
Message:
Logged In: YES
user_id=849994
Raymond, what to do in this case?
Note that other built-in types, such as list(), do accept
keyword arguments.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1486663 ] Over-zealous keyword-arguments check for built-in set class
Bugs item #1486663, was opened at 2006-05-11 16:17
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: dib (dib_at_work)
Assigned to: Georg Brandl (gbrandl)
Summary: Over-zealous keyword-arguments check for built-in set class
Initial Comment:
The fix for bug #1119418 (xrange() builtin accepts
keyword arg silently) included in Python 2.4.2c1+
breaks code that passes keyword argument(s) into
classes derived from the built-in set class, even if
those derived classes explictly accept those keyword
arguments and avoid passing them down to the built-in
base class.
Simplified version of code in attached
BuiltinSetKeywordArgumentsCheckBroken.py fails at (G)
due to bug #1119418 if version < 2.4.2c1; if version >=
2.4.2c1 (G) passes thanks to that bug fix, but instead
(H) incorrectly-in-my-view fails.
[Presume similar cases would fail for xrange and the
other classes mentioned in #1119418.]
-- David Bruce
(Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.)
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-01-11 19:56
Message:
Logged In: YES
user_id=849994
Originator: NO
Attaching patch.
File Added: nokeywordchecks.diff
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 18:30
Message:
Logged In: YES
user_id=80475
Originator: NO
I fixed setobject.c in revisions 53380 and 53381.
Please apply similar fixes to all the other places being bitten my the
pervasive NoKeywords tests.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 00:49
Message:
Logged In: YES
user_id=80475
Originator: NO
My proposed solution:
- if(!PyArg_NoKeywords("set()", kwds)
+ if(type == &PySet_Type && !PyArg_NoKeywords("set()", kwds)
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-01-10 21:30
Message:
Logged In: YES
user_id=849994
Originator: NO
I'll do that, only in set_init, you have
if (!PyArg_UnpackTuple(args, self->ob_type->tp_name, 0, 1, &iterable))
Changing this to use PyArg_ParseTupleAndKeywords would require a format
string of
"|O:" + self->ob_type->tp_name
Is it worth constructing that string each time set_init() is called or
should it just be "|O:set" for
sets and frozensets?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-06 02:26
Message:
Logged In: YES
user_id=80475
Originator: NO
I prefer the approach used by list().
--
Comment By: Žiga Seilnacht (zseil)
Date: 2006-05-20 01:19
Message:
Logged In: YES
user_id=1326842
See patch #1491939
--
Comment By: Žiga Seilnacht (zseil)
Date: 2006-05-19 20:02
Message:
Logged In: YES
user_id=1326842
This bug was introduced as part of the fix for bug #1119418.
It also affects collections.deque.
Can't the _PyArg_NoKeywords check simply be moved
to set_init and deque_init as it was done for
zipimport.zipimporter?
array.array doesn't need to be changed, since it
already does all of its initialization in its
__new__ method.
The rest of the types changed in that fix should not
be affected, since they are immutable.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-05-11 17:23
Message:
Logged In: YES
user_id=849994
Raymond, what to do in this case?
Note that other built-in types, such as list(), do accept
keyword arguments.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1632328 ] logging.config.fileConfig doesn't clear logging._handlerList
Bugs item #1632328, was opened at 2007-01-10 12:56 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1632328&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stefan H. Holek (shh42) Assigned to: Vinay Sajip (vsajip) Summary: logging.config.fileConfig doesn't clear logging._handlerList Initial Comment: logging.config.fileConfig resets logging._handlers but not logging._handlerList, resulting in tracebacks on shutdown. e.g. Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/local/python2.4/lib/python2.4/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/python2.4/lib/python2.4/logging/__init__.py", line 1333, in shutdown h.close() File "/usr/local/python2.4/lib/python2.4/logging/__init__.py", line 674, in close del _handlers[self] KeyError: AFAICT this is fixed in Python 2.5 but has not been backported. Zope cannot use 2.5 as of yet. -- >Comment By: Vinay Sajip (vsajip) Date: 2007-01-11 20:28 Message: Logged In: YES user_id=308438 Originator: NO Yes - fix checked into release24-maint. -- Comment By: Georg Brandl (gbrandl) Date: 2007-01-11 12:27 Message: Logged In: YES user_id=849994 Originator: NO Does a backport to 2.4 make sense? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1632328&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1534765 ] logging's fileConfig causes KeyError on shutdown
Bugs item #1534765, was opened at 2006-08-04 19:58 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534765&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: mdbeachy (mdbeachy) Assigned to: Vinay Sajip (vsajip) Summary: logging's fileConfig causes KeyError on shutdown Initial Comment: If logging.config.fileConfig() is called after logging handlers already exist, a KeyError is thrown in the atexit call to logging.shutdown(). This looks like it's fixed in the 2.5 branch but since I've bothered to figure out what was going on I'm sending this in anyway. There still might be a 2.4.4, right? (Also, my fix looks better than what was done for 2.5, but I suppose the flush/close I added may not be necessary.) Attached is a demo and a patch against 2.4.3. Thanks, Mike -- >Comment By: Vinay Sajip (vsajip) Date: 2007-01-11 20:30 Message: Logged In: YES user_id=308438 Originator: NO Fix for SF #1632328 should cover this - checked into release24-maint. -- Comment By: Matt Fleming (splitscreen) Date: 2006-08-09 14:10 Message: Logged In: YES user_id=1126061 Bug confirmed in release24-maint. Patch looks good to me, although I think the developers prefer unified diffs, not contextual, just to keep in mind for the future. And also, I had to manually patch the Lib/logging/config.py file because for some reason, the paths in your patch all use lowercase letters. Thanks for the patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534765&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1486663 ] Over-zealous keyword-arguments check for built-in set class
Bugs item #1486663, was opened at 2006-05-11 11:17
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: dib (dib_at_work)
Assigned to: Georg Brandl (gbrandl)
Summary: Over-zealous keyword-arguments check for built-in set class
Initial Comment:
The fix for bug #1119418 (xrange() builtin accepts
keyword arg silently) included in Python 2.4.2c1+
breaks code that passes keyword argument(s) into
classes derived from the built-in set class, even if
those derived classes explictly accept those keyword
arguments and avoid passing them down to the built-in
base class.
Simplified version of code in attached
BuiltinSetKeywordArgumentsCheckBroken.py fails at (G)
due to bug #1119418 if version < 2.4.2c1; if version >=
2.4.2c1 (G) passes thanks to that bug fix, but instead
(H) incorrectly-in-my-view fails.
[Presume similar cases would fail for xrange and the
other classes mentioned in #1119418.]
-- David Bruce
(Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.)
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 15:43
Message:
Logged In: YES
user_id=80475
Originator: NO
That looks about right. Please add test cases that fail without the patch
and succeed with the patch. Also, put a comment in Misc/NEWS. If the
whole test suite passes, go ahead and check-in to Py2.5.1 and the head.
Thanks,
Raymond
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-01-11 14:56
Message:
Logged In: YES
user_id=849994
Originator: NO
Attaching patch.
File Added: nokeywordchecks.diff
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 13:30
Message:
Logged In: YES
user_id=80475
Originator: NO
I fixed setobject.c in revisions 53380 and 53381.
Please apply similar fixes to all the other places being bitten my the
pervasive NoKeywords tests.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-10 19:49
Message:
Logged In: YES
user_id=80475
Originator: NO
My proposed solution:
- if(!PyArg_NoKeywords("set()", kwds)
+ if(type == &PySet_Type && !PyArg_NoKeywords("set()", kwds)
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-01-10 16:30
Message:
Logged In: YES
user_id=849994
Originator: NO
I'll do that, only in set_init, you have
if (!PyArg_UnpackTuple(args, self->ob_type->tp_name, 0, 1, &iterable))
Changing this to use PyArg_ParseTupleAndKeywords would require a format
string of
"|O:" + self->ob_type->tp_name
Is it worth constructing that string each time set_init() is called or
should it just be "|O:set" for
sets and frozensets?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-05 21:26
Message:
Logged In: YES
user_id=80475
Originator: NO
I prefer the approach used by list().
--
Comment By: Žiga Seilnacht (zseil)
Date: 2006-05-19 20:19
Message:
Logged In: YES
user_id=1326842
See patch #1491939
--
Comment By: Žiga Seilnacht (zseil)
Date: 2006-05-19 15:02
Message:
Logged In: YES
user_id=1326842
This bug was introduced as part of the fix for bug #1119418.
It also affects collections.deque.
Can't the _PyArg_NoKeywords check simply be moved
to set_init and deque_init as it was done for
zipimport.zipimporter?
array.array doesn't need to be changed, since it
already does all of its initialization in its
__new__ method.
The rest of the types changed in that fix should not
be affected, since they are immutable.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-05-11 12:23
Message:
Logged In: YES
user_id=849994
Raymond, what to do in this case?
Note that other built-in types, such as list(), do accept
keyword arguments.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-793764 ] pyconfig.h defines _POSIX_C_SOURCE, conflicting with feature
Bugs item #793764, was opened at 2003-08-23 16:19 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793764&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: Installation Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: pyconfig.h defines _POSIX_C_SOURCE, conflicting with feature Initial Comment: [forwarded from http://bugs.debian.org/206805] the installed include/python2.3/pyconfig.h defines _POSIX_C_SOURCE, which leaks down into packages built against python-2.3. AFAIK, _POSIX_C_SOURCE is reserved for use by the C library, and is of course defined in /usr/include/features.h. Example excerpt from a build log: In file included from /usr/include/python2.3/Python.h:8, from sg_config.h:22, from sg.h:29, from sg_project_autosave.c:26: /usr/include/python2.3/pyconfig.h:844:1: Warnung: "_POSIX_C_SOURCE" redefined In file included from /usr/include/stdlib.h:25, from sg_project_autosave.c:19: /usr/include/features.h:171:1: Warnung: this is the location of the previous definition -- >Comment By: Martin v. Löwis (loewis) Date: 2007-01-11 22:31 Message: Logged In: YES user_id=21627 Originator: NO Sure, and python.h does that: it defines _POSIX_C_SOURCE before any (system) header is included. The problem is rather in SciGraphica, which include Python.h in sg_config.h *after* including a system header. This is in violation of the Python API, as described in my initial message. -- Comment By: Matthias Klose (doko) Date: 2007-01-11 10:13 Message: Logged In: YES user_id=60903 Originator: YES 8. For the C programming language, shall define _POSIX_C_SOURCE to be 200112L before any header is included _POSIX_C_SOURCE should be defined "before any header is included". That phrase was taken from the following comments: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793764&group_id=5470 It's described at: Single Unix Specification 3: "2.2.1 Strictly Conforming POSIX Application" 8. -- Comment By: Martin v. Löwis (loewis) Date: 2003-08-31 19:26 Message: Logged In: YES user_id=21627 _POSIX_C_SOURCE is not reserved for the C library, but for the application, see http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html (section "Strictly Conforming POSIX Application") A conforming POSIX application *must* define _POSIX_C_SOURCE, so if your C library also defines it, it is a bug in the C library. Most likely, the author failed to include Python.h before other system headers, as required per http://www.python.org/doc/current/api/includes.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793764&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1630863 ] PyLong_AsLong doesn't check tp_as_number
Bugs item #1630863, was opened at 2007-01-08 20:06 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630863&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roger Upole (rupole) >Assigned to: Martin v. Löwis (loewis) Summary: PyLong_AsLong doesn't check tp_as_number Initial Comment: Both PyInt_AsLong and PyLong_AsLongLong check if an object's type has PyNumberMethods defined. However, PyLong_AsLong does not, causing conversion to fail for objects which can legitimately be converted to a long. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630863&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633583 ] Hangs with 100% CPU load for certain regexes
Bugs item #1633583, was opened at 2007-01-11 23:40 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=1633583&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: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Hangs with 100% CPU load for certain regexes Initial Comment: [forwarded from http://bugs.debian.org/401676] seen with 2.4.4 and 2.5 20061209; bug submitter writes: Hi, https://develop.participatoryculture.org/democracy/attachment/ticket/3947/crash.py is a small test program which causes a complete hangup for at least minutes (I aborted after a while) on my system, with 100% CPU load. The regex code seems to run into some endless loop or something... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633583&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633600 ] using locale does not display the intended behavior
Bugs item #1633600, was opened at 2007-01-11 23:59 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=1633600&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: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: using locale does not display the intended behavior Initial Comment: [forwarded from http://bugs.debian.org/405618] the locales are available on the system; the string.lowercase constant doesn't change. bug submitter writes: Hello, if I interpret correctly http://docs.python.org/lib/node746.html the characters 'é', 'ç' and so on should be members of string.lowercase when the locale is set on a french one. But as you can see here this is not the case: % python Python 2.4.4 (#2, Oct 20 2006, 00:23:25) [GCC 4.1.2 20061015 (prerelease) (Debian 4.1.1-16.1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'LC_CTYPE=fr_BE.UTF-8;LC_NUMERIC=fr_BE.UTF-8;LC_TIME=fr_BE.UTF-8;LC_COLLATE=C;LC_MONETARY=fr_BE.UTF-8;LC_MESSAGES=fr_BE.UTF-8;LC_PAPER=fr_BE.UTF-8;LC_NAME=fr_BE.UTF-8;LC_ADDRESS=fr_BE.UTF-8;LC_TELEPHONE=fr_BE.UTF-8;LC_MEASUREMENT=fr_BE.UTF-8;LC_IDENTIFICATION=fr_BE.UTF-8' >>> import string >>> string.lowercase 'abcdefghijklmnopqrstuvwxyz' I also tried to import string before the setlocale call or before the import locale call but it did not work either. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633600&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633605 ] logging module / wrong bytecode?
Bugs item #1633605, was opened at 2007-01-12 00:06
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=1633605&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: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging module / wrong bytecode?
Initial Comment:
[forwarded from http://bugs.debian.org/390152]
seen with python2.4 and python2.5 on debian unstable
import logging
logging.basicConfig(level=logging.DEBUG,
format='%(pathname)s:%(lineno)d')
logging.info('whoops')
The output when the logging/__init__.pyc file exists is:
logging/__init__.py:1072
and when the __init__.pyc is deleted the output becomes:
tst.py:5
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633605&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1630863 ] PyLong_AsLong doesn't check tp_as_number
Bugs item #1630863, was opened at 2007-01-08 21:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630863&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roger Upole (rupole) Assigned to: Martin v. Löwis (loewis) Summary: PyLong_AsLong doesn't check tp_as_number Initial Comment: Both PyInt_AsLong and PyLong_AsLongLong check if an object's type has PyNumberMethods defined. However, PyLong_AsLong does not, causing conversion to fail for objects which can legitimately be converted to a long. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-01-12 00:20 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the problem. If you want to convert arbitrary objects to long, use PyInt_AsLong. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630863&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633621 ] curses should reset curses.{COLS, LINES} when term. resized
Bugs item #1633621, was opened at 2007-01-12 00:38
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=1633621&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: 3
Private: No
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses should reset curses.{COLS,LINES} when term. resized
Initial Comment:
[forwarded from http://bugs.debian.org/366698]
The curses module does not reset curses.COLS and curses.LINES when the terminal
is resized.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633621&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633628 ] time.strftime() accepts format which time.strptime doesnt
Bugs item #1633628, was opened at 2007-01-12 00:44 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=1633628&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: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: time.strftime() accepts format which time.strptime doesnt Initial Comment: [forwarded from http://bugs.debian.org/354636] time.strftime() accepts '%F %T' as format but time.strptime() doesn't, if the rule is "all what strftime accepts strptime must also" then that is bad. Check this: darwin:~# python2.4 Python 2.4.2 (#2, Nov 20 2005, 17:04:48) [GCC 4.0.3 2005 (prerelease) (Debian 4.0.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> format = '%F %T' >>> t = time.strftime(format) >>> t '2006-02-27 18:09:37' >>> time.strptime(t,format) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/_strptime.py", line 287, in strptime format_regex = time_re.compile(format) File "/usr/lib/python2.4/_strptime.py", line 264, in compile return re_compile(self.pattern(format), IGNORECASE) File "/usr/lib/python2.4/_strptime.py", line 256, in pattern processed_format = "%s%s%s" % (processed_format, KeyError: 'F' >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633628&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633630 ] class derived from float evaporates under +=
Bugs item #1633630, was opened at 2007-01-12 00:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633630&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: Type/class unification Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: class derived from float evaporates under += Initial Comment: [forwarded from http://bugs.debian.org/345373] There seems to be a bug in classes derived from float. For instance, consider the following: >>> class Float(float): ... def __init__(self, v): ... float.__init__(self, v) ... self.x = 1 ... >>> a = Float(2.0) >>> b = Float(3.0) >>> type(a) >>> type(b) >>> a += b >>> type(a) Now, the type of a has silently changed. It was a Float, a derived class with all kinds of properties, and it became a float -- a plain vanilla number. My understanding is that this is incorrect, and certainly unexpected. If it *is* correct, it certainly deserves mention somewhere in the documentation. It seems that Float.__iadd__(a, b) should be called. This defaults to float.__iadd__(a, b), which should increment the float part of the object while leaving the rest intact. A possible explanation for this problem is that float.__iadd__ is not actually defined, and so it falls through to a = float.__add__(a, b), which assigns a float to a. This interpretation seems to be correct, as one can add a destructor to the Float class: >>> class FloatD(float): ... def __init__(self, v): ... float.__init__(self, v) ... self.x = 1 ... def __del__(self): ... print 'Deleting FloatD class, losing x=', self.x ... >>> a = FloatD(2.0) >>> b = FloatD(3.0) >>> a += b Deleting FloatD class, losing x= 1 >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633630&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633648 ] incomplete numerical comparisons
Bugs item #1633648, was opened at 2007-01-12 01:18 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=1633648&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: incomplete numerical comparisons Initial Comment: [forwarded from http://bugs.debian.org/334022] bug submitter writes: I've been tracking down the regression failure in python-pgsql under python2.[45], and here's what it comes down to. Python-pgsql includes a short int type named PgInt2, which allows itself to be coerced into all of the usual numeric types. The regression that fails is when a PgInt2 is compared with a float. In this case python determines that the comparison is not implemented. The problem is this: - Under python2.[45], the float type includes tp_richcompare but not tp_compare. - When calling try_rich_to_3way_compare(), python does not try any kind of numeric coercion, and so the comparison fails. - When calling try_3way_compare(), python successfully coerces the PgInt2 into a float, but then the comparison fails because the float type has no tp_compare routine. Presumably what would fix things would be one of the following: - Bring back the trivial float_compare() routine, which was removed with python2.[45] when they brought in the new float_richcompare() instead; - In try_3way_compare(), if the coercion succeeds and neither object has a tp_compare routine, try tp_richcompare before failing completely. Does either of these solutions seem feasible? Thanks - Ben. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633648&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633665 ] file(file) should succeed
Bugs item #1633665, was opened at 2007-01-12 01:50
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=1633665&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 3
Private: No
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: file(file) should succeed
Initial Comment:
[forwarded from http://bugs.debian.org/327060]
Many types in Python are idempotent, so that int(1) works
as expected, float(2.34)==2.34, ''.join('hello')=='hello'
et cetera.
Why not file()? Currently, file(open(something, 'r')) fails
with "TypeError: coercing to Unicode: need string or buffer, file found."
Semantically, file(fd) should be equivalent to os.fdopen(fd.fileno())
or the proposed file.fromfd() (Jp Calderone, Python-dev, 2003).
You should get another independent
file object that accesses the same file.
What would be gained?
Primarily, it would allow you to derive classes from file more easily.
At present, if you want to derive like so, you're class can only work
when passed a file name or buffer.
class file_with_caching(file):
def __init__(self, something):
file.__init__(self, something)
def etcetera...
For instance, you have no way of creating a file_with_caching()
object from the file descriptors returned from os.fork().
Also, you have no way of taking a file that is already open,
and creating a file_with_caching() object from it.So,
you can't use classes derived from file() on the standard input
or standard output.
This breaks the nice Linux OS-level definition of a file descriptor.
At the Linux level, you have a nice uniform interface where all
file descriptors are equally good.At the python level, some
are better than others. It's a case where Python unnecessarily
restricts what you can do.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633665&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633678 ] mailbox.py _fromlinepattern regexp does not support positive
Bugs item #1633678, was opened at 2007-01-12 02:14 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=1633678&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: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox.py _fromlinepattern regexp does not support positive Initial Comment: [forwarded from http://bugs.debian.org/254757] mailbox.py _fromlinepattern regexp does not support positive GMT offsets. the pattern didn't change in 2.5. bug submitter writes: archivemail incorrectly splits up messages in my mbox-format mail archvies. I use Squirrelmail, which seems to create mbox lines that look like this: >From [EMAIL PROTECTED] Mon Jan 26 12:29:24 2004 -0400 The "-0400" appears to be throwing it off. If the first message of an mbox file has such a line on it, archivemail flat out stops, saying the file is not mbox. If the later messages in an mbox file are in this style, they are not counted, and archivemail thinks that the preceding message is just kind of long, and the decision to archive or not is broken. I have stumbled on this bug when I wanted to archive my mails on a Sarge system. And since my TZ is positive, the regexp did not work. I think the correct regexp for /usr/lib/python2.3/mailbox.py should be: _fromlinepattern = r"From \s*[^\s]+\s+\w\w\w\s+\w\w\w\s+\d?\d\s+" \ r"\d?\d:\d\d(:\d\d)?(\s+[^\s]+)?\s+\d\d\d\d\s*((\+|-)\d\d\d\d)?\s*$" This should handle positive and negative timezones in From lines. I have tested it successfully with an email beginning with this line: >From [EMAIL PROTECTED] Mon May 31 13:24:50 2004 +0200 as well as one withouth TZ reference. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633678&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633583 ] Hangs with 100% CPU load for certain regexes
Bugs item #1633583, was opened at 2007-01-11 22:40
Message generated for change (Comment added) made by niemeyer
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633583&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: Wont Fix
Priority: 5
Private: No
Submitted By: Matthias Klose (doko)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Hangs with 100% CPU load for certain regexes
Initial Comment:
[forwarded from http://bugs.debian.org/401676]
seen with 2.4.4 and 2.5 20061209; bug submitter writes:
Hi,
https://develop.participatoryculture.org/democracy/attachment/ticket/3947/crash.py
is a small test program which causes a complete hangup for at least
minutes (I aborted after a while) on my system, with 100% CPU load. The
regex code seems to run into some endless loop or something...
--
>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2007-01-12 01:42
Message:
Logged In: YES
user_id=7887
Originator: NO
Hello Matthias,
It's well known that certain regular expressions can match in exponential
time.
Try that for instance: re.match("(((a+?)+?)+?b)", "a"*100+"c")
There are ways to optimize simple cases like this (which aren't present in
Python right now), but there isn't a way to truly "solve" the exponential
time backtracking for all cases while still offering the current feature
set.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633583&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1025525 ] asyncore.file_dispatcher should not take fd as argument
Bugs item #1025525, was opened at 2004-09-10 12:14 Message generated for change (Comment added) made by dhoulder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025525&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: david houlder (dhoulder) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore.file_dispatcher should not take fd as argument Initial Comment: Only relevant to posix. asyncore.file_dispatcher closes the file descriptor behind the file object, and not the file object itself. When another file gets opened, it gets the next available fd, which on posix, is the one just released by the close. Tested on python 2.2.3 on RedHat Enterprise Linux 3 and python 2.2.1 on HP Tru64 unix. See attached script for details and a solution. 'case 1' should show the problem regardless of the garbage collection strategy in python. 'case 2' relies on the file object being closed as soon as the last reference to it disappears, which seems to be the (current?) behaviour. [EMAIL PROTECTED] djh900]$ python file_dispatcher_bug.py case 1: (Read 'I am the first pipe\n' from pipe) (pipe closing. fd== 3 ) (Read '' from pipe) firstPipe.read() says 'I am the second pipe\n' firstPipe.fileno()== 3 secondPipe.fileno()== 3 case 2: (Read 'I am the first pipe\n' from pipe) (pipe closing. fd== 3 ) (Read '' from pipe) secondPipe.fileno()== 3 dispatcher.secondPipe.read() says Traceback (most recent call last): File "file_dispatcher_bug.py", line 77, in ? print "dispatcher.secondPipe.read() says", repr(dispatcher.secondPipe.read()) IOError: [Errno 9] Bad file descriptor [EMAIL PROTECTED] djh900]$ -- >Comment By: david houlder (dhoulder) Date: 2007-01-12 12:58 Message: Logged In: YES user_id=1119185 Originator: YES Yep, dup()ing the fd and using that for the lifetime of the object sounds like a good, simple fix. Wish I'd thought of it :-) -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-07 09:48 Message: Logged In: YES user_id=341410 Originator: NO I believe that asyncore.file_dispatcher taking a file descriptor is fine. The problem is that the documentation doesn't suggest that you os.dup() the file handle so that both the original handle (from a pipe, file, etc.) can be closed independently from the one being used by the file_dispatcher. In the case of socket.makefile(), the duplication is done automatically, so there isn't the same problem. My suggested fix would be to accept a file or a file handle. For files, we first get its file number via the standard f.fileno(), and with that, or the handle we are provided, we os.dup() the handle. -- Comment By: david houlder (dhoulder) Date: 2004-11-18 10:43 Message: Logged In: YES user_id=1119185 In an ideal world I'd propose replacing the guts of file_wrapper() and file_dispatcher() by my pipe_wrapper() and PipeDispatcher(), since the general problem of closing the file descriptor behind the python object applies to all python objects that are based on a file descriptor, not just pipes. So, yes, probably best not to call it pipe_dispatcher(). And I guess file_dispatcher() may be in use by other peoples' code and changing it to take a file object rather than an fd will break that. Maybe file_dispatcher.__init__() could be changed to take either an integer file descriptor or a file object as it's argument, and behave like the current file_dispatcher() when given an fd, and like pipe_dispatcher() when given a file-like object (i.e. any object with fileno() and close() methods will probably be enough). I'm happy to whip up an example if people think that's a good idea. -- Comment By: Jeremy Hylton (jhylton) Date: 2004-11-08 02:23 Message: Logged In: YES user_id=31392 I'm not sure whether you propose a change to asyncore or are describing a pattern that allows you to use a pipe with it safely. And, looking at your code more closely, I think pipe is confusing, because you're not talking about os.pipe() right? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1630863 ] PyLong_AsLong doesn't check tp_as_number
Bugs item #1630863, was opened at 2007-01-08 15:06 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630863&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roger Upole (rupole) Assigned to: Martin v. Löwis (loewis) Summary: PyLong_AsLong doesn't check tp_as_number Initial Comment: Both PyInt_AsLong and PyLong_AsLongLong check if an object's type has PyNumberMethods defined. However, PyLong_AsLong does not, causing conversion to fail for objects which can legitimately be converted to a long. -- >Comment By: Roger Upole (rupole) Date: 2007-01-11 21:11 Message: Logged In: YES user_id=771074 Originator: YES The problem is that the conversion fails when it should succeed. The place I ran into this was in PyLong_AsVoidPtr, which I can't change. Are you saying that PyLong_AsLong is deprecated, and should never be used ? -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-11 18:20 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the problem. If you want to convert arbitrary objects to long, use PyInt_AsLong. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630863&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1504333 ] sgmllib should allow angle brackets in quoted values
Bugs item #1504333, was opened at 2006-06-11 05:58
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504333&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: Sam Ruby (rubys)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib should allow angle brackets in quoted values
Initial Comment:
Real live example (search for "othercorrections")
http://latticeqcd.blogspot.com/2006/05/non-relativistic-qcd.html
This addresses the following (included in the file):
# XXX The following should skip matching quotes (' or ")
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-11 22:04
Message:
Logged In: YES
user_id=33168
Originator: NO
You should be able to check yourself. Use the current version of Python,
apply the test case from the original patch and your patch to the code. If
the test passes, I'll be happy to check in the fix. If that does work,
please create a new patch with your code and the test case from the
original patch.
--
Comment By: Haejoong Lee (haepal)
Date: 2007-01-11 10:01
Message:
Logged In: YES
user_id=135609
Originator: NO
Could someone check if the following patch fixes the problem?
This patch was made against revision 51854.
--- sgmllib.py.org 2006-11-06 02:31:12.0 -0500
+++ sgmllib.py 2007-01-11 12:39:30.0 -0500
@@ -16,6 +16,35 @@
# Regular expressions used for parsing
+class MyMatch:
+def __init__(self, i):
+self._i = i
+def start(self, i):
+return self._i
+
+class EndBracket:
+def search(self, data, index):
+s = data[index:]
+bs = None
+quote = None
+for i,c in enumerate(s):
+if bs:
+bs = False
+else:
+if c == '<' or c == '>':
+if quote is None:
+break
+elif c == "'" or c == '"':
+if c == quote:
+quote = None
+else:
+quote = c
+elif c == '\\':
+bs = True
+else:
+return None
+return MyMatch(i+index)
+
interesting = re.compile('[&<]')
incomplete = re.compile('&([a-zA-Z][a-zA-Z0-9]*|#[0-9]*)?|'
'<([a-zA-Z][^<>]*|'
@@ -29,7 +58,8 @@
shorttagopen = re.compile('<[a-zA-Z][-.a-zA-Z0-9]*/')
shorttag = re.compile('<([a-zA-Z][-.a-zA-Z0-9]*)/([^/]*)/')
piclose = re.compile('>')
-endbracket = re.compile('[<>]')
+#endbracket = re.compile('[<>]')
+endbracket = EndBracket()
tagfind = re.compile('[a-zA-Z][-_.a-zA-Z0-9]*')
attrfind = re.compile(
r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=\s*'
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-10 21:26
Message:
Logged In: YES
user_id=33168
I reverted the patch and added the test case for sgml so the
infinite loop doesn't recur. This was mentioned several
times on python-dev.
Committed revision 51854. (head)
Committed revision 51850. (2.5)
Committed revision 51853. (2.4)
--
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-06-29 10:17
Message:
Logged In: YES
user_id=3066
I checked in a modified version of this patch: changed to
use separate REs for start and end tags to reduce matching
cost for end tags; extended tests; updated to avoid breaking
previous changes to support IPv6 addresses in unquoted
attribute values.
Committed as revisions 47154 (trunk) and 47155
(release24-maint).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504333&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1630863 ] PyLong_AsLong doesn't check tp_as_number
Bugs item #1630863, was opened at 2007-01-08 21:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630863&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 Private: No Submitted By: Roger Upole (rupole) Assigned to: Martin v. Löwis (loewis) Summary: PyLong_AsLong doesn't check tp_as_number Initial Comment: Both PyInt_AsLong and PyLong_AsLongLong check if an object's type has PyNumberMethods defined. However, PyLong_AsLong does not, causing conversion to fail for objects which can legitimately be converted to a long. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-01-12 08:46 Message: Logged In: YES user_id=21627 Originator: NO No, I'm saying that PyLong_AsVoidPtr is guaranteed to convert ints and longs, nothing else. Likewise, PyLong_AsVoidPtr is only supported for int and long objects (read the documentation). It's not deprecated - but it should only be used for the cases which it is documented to support. If, for some reason, you want to convert an object that is not an int or long into a void*, by converting it to an int first, you need to invoke the number methods first yourself. Closing this report as invalid. -- Comment By: Roger Upole (rupole) Date: 2007-01-12 03:11 Message: Logged In: YES user_id=771074 Originator: YES The problem is that the conversion fails when it should succeed. The place I ran into this was in PyLong_AsVoidPtr, which I can't change. Are you saying that PyLong_AsLong is deprecated, and should never be used ? -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-12 00:20 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the problem. If you want to convert arbitrary objects to long, use PyInt_AsLong. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630863&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
