[ python-Bugs-1542016 ] inconsistency in PCALL conditional code in ceval.c
Bugs item #1542016, was opened at 2006-08-17 16:21
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=1542016&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
Submitted By: Santiago Gala (sgala)
Assigned to: Nobody/Anonymous (nobody)
Summary: inconsistency in PCALL conditional code in ceval.c
Initial Comment:
While there are macros to profile PCALL_POP, the
reporting of it via sys.callstats() is broken.
This patch solves it.
Index: Python/ceval.c
===
--- Python/ceval.c (revisión: 51339)
+++ Python/ceval.c (copia de trabajo)
@@ -186,10 +186,10 @@
PyObject *
PyEval_GetCallStats(PyObject *self)
{
- return Py_BuildValue("ii",
+ return Py_BuildValue("iii",
pcall[0], pcall[1],
pcall[2], pcall[3],
pcall[4], pcall[5],
pcall[6], pcall[7],
-pcall[8], pcall[9]);
+pcall[8], pcall[9],
pcall[10]);
}
#else
#define PCALL(O)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542016&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1528802 ] Turkish Character
Bugs item #1528802, was opened at 2006-07-26 09:05
Message generated for change (Comment added) made by sgala
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Ahmet Bişkinler (ahmetbiskinler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Turkish Character
Initial Comment:
>>> print "Mayıs".upper()
>>> MAYıS
>>> import locale
>>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254')
>>> print "Mayıs".upper()
>>> MAYıS
>>> print "ğüşiöçı".upper()
>>> ğüşIöçı
MAYıS should be MAYIS
ğüşIöçı should be ĞÜŞİÖÇI
but
>>> "Mayıs".upper()
>>> "MAYIS"
is right
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-17 16:53
Message:
Logged In: YES
user_id=178886
The behaviour of python in this area is confusing. See a
session with my Spanish keyboard:
>>> print "á"
á
>>> print len("á")
2
>>> print "á".upper()
á
>>> str("á")
'\xc3\xa1'
>>> print u"á"
á
>>> print len(u"á")
1
>>> print u"á".upper()
Á
>>> str(u"á")
Traceback (most recent call last):
File "", line 1, in
__builtin__.UnicodeEncodeError: 'ascii' codec can't encode
character u'\xe1' in position 0: ordinal not in range(128)
I guess this is what is happening to the reporter.
This violates the least surprising behavior principle in so
many different ways that it hurts. Can anybody make sense of it?
--
Comment By: Ahmet Bişkinler (ahmetbiskinler)
Date: 2006-08-11 10:10
Message:
Logged In: YES
user_id=1481281
What happened?
Is it solved?
How is it going?
What is the final step?
...?
...?
Could you please give me some information about the bug please?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1528802 ] Turkish Character
Bugs item #1528802, was opened at 2006-07-26 09:05
Message generated for change (Comment added) made by sgala
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Ahmet Bişkinler (ahmetbiskinler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Turkish Character
Initial Comment:
>>> print "Mayıs".upper()
>>> MAYıS
>>> import locale
>>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254')
>>> print "Mayıs".upper()
>>> MAYıS
>>> print "ğüşiöçı".upper()
>>> ğüşIöçı
MAYıS should be MAYIS
ğüşIöçı should be ĞÜŞİÖÇI
but
>>> "Mayıs".upper()
>>> "MAYIS"
is right
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-17 16:59
Message:
Logged In: YES
user_id=178886
(I tested it in 2.5rc1), 2.4 gives
>>> str(u"á")
'\xc3\xa1'
instead of the exception
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-17 16:53
Message:
Logged In: YES
user_id=178886
The behaviour of python in this area is confusing. See a
session with my Spanish keyboard:
>>> print "á"
á
>>> print len("á")
2
>>> print "á".upper()
á
>>> str("á")
'\xc3\xa1'
>>> print u"á"
á
>>> print len(u"á")
1
>>> print u"á".upper()
Á
>>> str(u"á")
Traceback (most recent call last):
File "", line 1, in
__builtin__.UnicodeEncodeError: 'ascii' codec can't encode
character u'\xe1' in position 0: ordinal not in range(128)
I guess this is what is happening to the reporter.
This violates the least surprising behavior principle in so
many different ways that it hurts. Can anybody make sense of it?
--
Comment By: Ahmet Bişkinler (ahmetbiskinler)
Date: 2006-08-11 10:10
Message:
Logged In: YES
user_id=1481281
What happened?
Is it solved?
How is it going?
What is the final step?
...?
...?
Could you please give me some information about the bug please?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1528802 ] Turkish Character
Bugs item #1528802, was opened at 2006-07-26 07:05
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Ahmet Bişkinler (ahmetbiskinler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Turkish Character
Initial Comment:
>>> print "Mayıs".upper()
>>> MAYıS
>>> import locale
>>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254')
>>> print "Mayıs".upper()
>>> MAYıS
>>> print "ğüşiöçı".upper()
>>> ğüşIöçı
MAYıS should be MAYIS
ğüşIöçı should be ĞÜŞİÖÇI
but
>>> "Mayıs".upper()
>>> "MAYIS"
is right
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 15:03
Message:
Logged In: YES
user_id=849994
sgala: it looks like your console sends UTF-8 encoded text.
>>> print "á"
á
print is just printing out a byte string consisting of two
bytes, which your console displays as accent-a.
>>> print len("á")
2
A UTF-8-encoded string containing an accented a has two bytes.
>>> print "á".upper()
á
str.upper() doesn't take locale into account, so the
accented a has no uppercase version defined.
>>> str("á")
'\xc3\xa1'
str() applied to a byte string returns that byte string.
Since return values from functions are printed by the
interactive interpreter using repr() first, you get this
representation (which you could also get from "print
repr('a')".)
>>> print u"á"
á
That's also okay. Python knows the terminal encoding and
properly translates the byte string to a unicode string of
one character. On printout, it converts it to a UTF-8 string
again, which your terminal displays correctly.
>>> print len(u"á")
1
Since your two-byte-UTF-8 sequence is converted to a unicode
character, the length of this unicode string is 1.
>>> print u"á".upper()
Á
There are comprehensive capitalization tables available for
unicode.
>>> str(u"á")
Traceback (most recent call last):
File "", line 1, in
__builtin__.UnicodeEncodeError: 'ascii' codec
can't encode
character u'\xe1' in position 0: ordinal not in
range(128)
Applying str() to a unicode string must convert it to a byte
string. If you don't specify an encoding, the default
encoding is "ascii", which can't encode the accented a. Use
"a".encode("utf-8").
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-17 14:59
Message:
Logged In: YES
user_id=178886
(I tested it in 2.5rc1), 2.4 gives
>>> str(u"á")
'\xc3\xa1'
instead of the exception
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-17 14:53
Message:
Logged In: YES
user_id=178886
The behaviour of python in this area is confusing. See a
session with my Spanish keyboard:
>>> print "á"
á
>>> print len("á")
2
>>> print "á".upper()
á
>>> str("á")
'\xc3\xa1'
>>> print u"á"
á
>>> print len(u"á")
1
>>> print u"á".upper()
Á
>>> str(u"á")
Traceback (most recent call last):
File "", line 1, in
__builtin__.UnicodeEncodeError: 'ascii' codec can't encode
character u'\xe1' in position 0: ordinal not in range(128)
I guess this is what is happening to the reporter.
This violates the least surprising behavior principle in so
many different ways that it hurts. Can anybody make sense of it?
--
Comment By: Ahmet Bişkinler (ahmetbiskinler)
Date: 2006-08-11 08:10
Message:
Logged In: YES
user_id=1481281
What happened?
Is it solved?
How is it going?
What is the final step?
...?
...?
Could you please give me some information about the bug please?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1528802 ] Turkish Character
Bugs item #1528802, was opened at 2006-07-26 09:05
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Ahmet Bişkinler (ahmetbiskinler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Turkish Character
Initial Comment:
>>> print "Mayıs".upper()
>>> MAYıS
>>> import locale
>>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254')
>>> print "Mayıs".upper()
>>> MAYıS
>>> print "ğüşiöçı".upper()
>>> ğüşIöçı
MAYıS should be MAYIS
ğüşIöçı should be ĞÜŞİÖÇI
but
>>> "Mayıs".upper()
>>> "MAYIS"
is right
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-08-17 17:04
Message:
Logged In: YES
user_id=38388
String upper and lower conversion are locale dependent and
implemented by the underlying libc, whereas Unicode
upper/lower conversion is not and only depends on the
Unicode character database.
OTOH, there are special cases where the standard Unicode
upper/lower mapping is no what you might expect, since the
database only provides a single mapping and is not context
aware.
There's nothing we can do if the libc is broken in some
respect. As for the extended case mapping support in
Unicode: patches are welcome.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 17:03
Message:
Logged In: YES
user_id=849994
sgala: it looks like your console sends UTF-8 encoded text.
>>> print "á"
á
print is just printing out a byte string consisting of two
bytes, which your console displays as accent-a.
>>> print len("á")
2
A UTF-8-encoded string containing an accented a has two bytes.
>>> print "á".upper()
á
str.upper() doesn't take locale into account, so the
accented a has no uppercase version defined.
>>> str("á")
'\xc3\xa1'
str() applied to a byte string returns that byte string.
Since return values from functions are printed by the
interactive interpreter using repr() first, you get this
representation (which you could also get from "print
repr('a')".)
>>> print u"á"
á
That's also okay. Python knows the terminal encoding and
properly translates the byte string to a unicode string of
one character. On printout, it converts it to a UTF-8 string
again, which your terminal displays correctly.
>>> print len(u"á")
1
Since your two-byte-UTF-8 sequence is converted to a unicode
character, the length of this unicode string is 1.
>>> print u"á".upper()
Á
There are comprehensive capitalization tables available for
unicode.
>>> str(u"á")
Traceback (most recent call last):
File "", line 1, in
__builtin__.UnicodeEncodeError: 'ascii' codec
can't encode
character u'\xe1' in position 0: ordinal not in
range(128)
Applying str() to a unicode string must convert it to a byte
string. If you don't specify an encoding, the default
encoding is "ascii", which can't encode the accented a. Use
"a".encode("utf-8").
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-17 16:59
Message:
Logged In: YES
user_id=178886
(I tested it in 2.5rc1), 2.4 gives
>>> str(u"á")
'\xc3\xa1'
instead of the exception
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-17 16:53
Message:
Logged In: YES
user_id=178886
The behaviour of python in this area is confusing. See a
session with my Spanish keyboard:
>>> print "á"
á
>>> print len("á")
2
>>> print "á".upper()
á
>>> str("á")
'\xc3\xa1'
>>> print u"á"
á
>>> print len(u"á")
1
>>> print u"á".upper()
Á
>>> str(u"á")
Traceback (most recent call last):
File "", line 1, in
__builtin__.UnicodeEncodeError: 'ascii' codec can't encode
character u'\xe1' in position 0: ordinal not in range(128)
I guess this is what is happening to the reporter.
This violates the least surprising behavior principle in so
many different ways that it hurts. Can anybody make sense of it?
--
Comment By: Ahmet Bişkinler (ahmetbiskinler)
Date: 2006-08-11 10:10
Message:
Logged In: YES
user_id=1481281
What happened?
Is it solved?
How is it going?
What is the final step?
...?
...?
Could you please give me some information about the bug please?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-a
[ python-Bugs-1528802 ] Turkish Character
Bugs item #1528802, was opened at 2006-07-26 07:05
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Ahmet Bişkinler (ahmetbiskinler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Turkish Character
Initial Comment:
>>> print "Mayıs".upper()
>>> MAYıS
>>> import locale
>>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254')
>>> print "Mayıs".upper()
>>> MAYıS
>>> print "ğüşiöçı".upper()
>>> ğüşIöçı
MAYıS should be MAYIS
ğüşIöçı should be ĞÜŞİÖÇI
but
>>> "Mayıs".upper()
>>> "MAYIS"
is right
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 15:08
Message:
Logged In: YES
user_id=849994
Using Unicode strings, the OP's example works.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-08-17 15:04
Message:
Logged In: YES
user_id=38388
String upper and lower conversion are locale dependent and
implemented by the underlying libc, whereas Unicode
upper/lower conversion is not and only depends on the
Unicode character database.
OTOH, there are special cases where the standard Unicode
upper/lower mapping is no what you might expect, since the
database only provides a single mapping and is not context
aware.
There's nothing we can do if the libc is broken in some
respect. As for the extended case mapping support in
Unicode: patches are welcome.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 15:03
Message:
Logged In: YES
user_id=849994
sgala: it looks like your console sends UTF-8 encoded text.
>>> print "á"
á
print is just printing out a byte string consisting of two
bytes, which your console displays as accent-a.
>>> print len("á")
2
A UTF-8-encoded string containing an accented a has two bytes.
>>> print "á".upper()
á
str.upper() doesn't take locale into account, so the
accented a has no uppercase version defined.
>>> str("á")
'\xc3\xa1'
str() applied to a byte string returns that byte string.
Since return values from functions are printed by the
interactive interpreter using repr() first, you get this
representation (which you could also get from "print
repr('a')".)
>>> print u"á"
á
That's also okay. Python knows the terminal encoding and
properly translates the byte string to a unicode string of
one character. On printout, it converts it to a UTF-8 string
again, which your terminal displays correctly.
>>> print len(u"á")
1
Since your two-byte-UTF-8 sequence is converted to a unicode
character, the length of this unicode string is 1.
>>> print u"á".upper()
Á
There are comprehensive capitalization tables available for
unicode.
>>> str(u"á")
Traceback (most recent call last):
File "", line 1, in
__builtin__.UnicodeEncodeError: 'ascii' codec
can't encode
character u'\xe1' in position 0: ordinal not in
range(128)
Applying str() to a unicode string must convert it to a byte
string. If you don't specify an encoding, the default
encoding is "ascii", which can't encode the accented a. Use
"a".encode("utf-8").
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-17 14:59
Message:
Logged In: YES
user_id=178886
(I tested it in 2.5rc1), 2.4 gives
>>> str(u"á")
'\xc3\xa1'
instead of the exception
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-17 14:53
Message:
Logged In: YES
user_id=178886
The behaviour of python in this area is confusing. See a
session with my Spanish keyboard:
>>> print "á"
á
>>> print len("á")
2
>>> print "á".upper()
á
>>> str("á")
'\xc3\xa1'
>>> print u"á"
á
>>> print len(u"á")
1
>>> print u"á".upper()
Á
>>> str(u"á")
Traceback (most recent call last):
File "", line 1, in
__builtin__.UnicodeEncodeError: 'ascii' codec can't encode
character u'\xe1' in position 0: ordinal not in range(128)
I guess this is what is happening to the reporter.
This violates the least surprising behavior principle in so
many different ways that it hurts. Can anybody make sense of it?
--
Comment By: Ahmet Bişkinler (ahmetbiskinler)
Date: 2006-08-11 08:10
Message:
Logged In: YES
user_id=1481281
What happened?
Is it solved?
How is it going?
What is the final step?
...?
...?
Could you please give me some information about the bug please?
--
You can respond by visiting:
https://sourceforge.net/trac
[ python-Bugs-1542051 ] Exceptions don't call _PyObject_GC_UNTRACK(self)
Bugs item #1542051, was opened at 2006-08-17 17:21 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=1542051&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 Submitted By: �iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Exceptions don't call _PyObject_GC_UNTRACK(self) Initial Comment: If I understand the GC rules correctly, BaseException and its subclasses should call _PyObject_GC_UNTRACK in their tp_dealloc methods. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1541642 ] Compiler command percent-sign causes format string error
Bugs item #1541642, was opened at 2006-08-16 18:39 Message generated for change (Settings changed) made by mdcowles You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541642&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: Distutils Group: Python 2.4 >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler command percent-sign causes format string error Initial Comment: [From a question posted to python-help] Using Sun's compiler, distutils generates a command line with a percent-sign in it: cc -DNDEBUG -xO3 -xtarget=native -xbuiltin=%all -xdepend=yes - xlibmil -xlibmopt -xstrconst -Xa -I/opt/pkg/include/db4 -I/usr/ include -I/opt/pkg/include -xcode=pic32 -OPT:Olimit=0 -I. -I/opt/ pkg.obj/lang/python24/work.e450/Python-2.4.3/./Include -I/opt/ pkg/include -I/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/ Include -I/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3 -c / opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Modules/ structmodule.c -o build/temp.solaris-2.10-sun4u-2.4/structmodule.o It seems that the percent-sign in "-xbuiltin=%all" isn't escaped when distutils goes to print the line and a format string error occurs: File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 Here's the full traceback: running build running build_ext INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension Traceback (most recent call last): File "./setup.py", line 1105, in ? main() File "./setup.py", line 1099, in main scripts = ['Tools/scripts/pydoc2.4', File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/core.py", line 149, in setup dist.run_commands() File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/dist.py", line 966, in run_command cmd_obj.run() File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/dist.py", line 966, in run_command cmd_obj.run() File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 179, in build_extensions build_ext.build_extensions(self) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 184, in build_extension build_ext.build_extension(self, ext) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/command/build_ext.py", line 470, in build_extension depends=ext.depends) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/ccompiler.py", line 699, in compile self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/unixccompiler.py", line 112, in _compile self.spawn(self.compiler_so + cc_args + [src, '-o', obj] + File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/ccompiler.py", line 1040, in spawn spawn (cmd, dry_run=self.dry_run) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/spawn.py", line 37, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/spawn.py", line 122, in _spawn_posix log.info(string.join(cmd, ' ')) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/log.py", line 33, in info self._log(INFO, msg, args) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 (I'm posting this for the person who originally ran into the error and asked about it on python-help.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541642&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542166 ] global variable: multiple id()-addresses
Bugs item #1542166, was opened at 2006-08-17 14:37 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=1542166&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Frank R. Schaefer (fschaef) Assigned to: Nobody/Anonymous (nobody) Summary: global variable: multiple id()-addresses Initial Comment: The **attachment** contains an example where one single global variable appears at two different positions when applying the 'id(...)' function. The following files are attached: core.py: contains the definition of the global variable, two example functions, and a minimal class definition. test.py: a test program displaying that the global variable in core.py has two addresses. result.txt: the output of the test.py procedure. In practical this means that a variable 'my_module.global_var' may refer to two different objects! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542166&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542166 ] global variable: multiple id()-addresses
Bugs item #1542166, was opened at 2006-08-17 18:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542166&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Frank R. Schaefer (fschaef) Assigned to: Nobody/Anonymous (nobody) Summary: global variable: multiple id()-addresses Initial Comment: The **attachment** contains an example where one single global variable appears at two different positions when applying the 'id(...)' function. The following files are attached: core.py: contains the definition of the global variable, two example functions, and a minimal class definition. test.py: a test program displaying that the global variable in core.py has two addresses. result.txt: the output of the test.py procedure. In practical this means that a variable 'my_module.global_var' may refer to two different objects! -- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 18:54 Message: Logged In: YES user_id=849994 In not_so_simple(), you *reassign* global_var. That means that it is bound to a different object afterwards. The name "global_var" you imported into the test module, however, is bound to the original global_var object, and this binding will not change. If that's not what you want, you'll have to do "import core" and refer to "core.global_var". Additionally, let me point out that using "global" to declare a name as global in a function that does not reassign that name is unnecessary. Closing as Invalid. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542166&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542051 ] Exceptions don't call _PyObject_GC_UNTRACK(self)
Bugs item #1542051, was opened at 2006-08-17 15:21 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&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: 7 Submitted By: �iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Exceptions don't call _PyObject_GC_UNTRACK(self) Initial Comment: If I understand the GC rules correctly, BaseException and its subclasses should call _PyObject_GC_UNTRACK in their tp_dealloc methods. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1528802 ] Turkish Character
Bugs item #1528802, was opened at 2006-07-26 09:05
Message generated for change (Comment added) made by sgala
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Ahmet Bişkinler (ahmetbiskinler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Turkish Character
Initial Comment:
>>> print "Mayıs".upper()
>>> MAYıS
>>> import locale
>>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254')
>>> print "Mayıs".upper()
>>> MAYıS
>>> print "ğüşiöçı".upper()
>>> ğüşIöçı
MAYıS should be MAYIS
ğüşIöçı should be ĞÜŞİÖÇI
but
>>> "Mayıs".upper()
>>> "MAYIS"
is right
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-17 20:58
Message:
Logged In: YES
user_id=178886
Idle from 2.5rc1 (svn today) produces a different result
than console (with my default, utf-8, encoding):
IDLE 1.2c1
>>> print "á"
á
>>> print len("á")
2
>>> print "á".upper()
á
>>> str("á")
'\xc3\xa1'
>>> print u"á"
á
>>> print len(u"á")
2
>>> print u"á".upper()
á
>>> str(u"á")
Traceback (most recent call last):
File "", line 1, in
str(u"á")
UnicodeEncodeError: 'ascii' codec can't encode characters in
position 0-1: ordinal not in range(128)
Again, IDLE 1.1.3 (python 2.4.3) produces a different result:
IDLE 1.1.3
>>> print "á"
á
>>> print len("á")
2
>>> print "á".upper()
á
>>> str("á")
'\xc3\xa1'
>>> print u"á"
á
>>> print len(u"á")
2
>>> print u"á".upper()
á
>>> str(u"á")
'\xc3\x83\xc2\xa1'
>>>
I'd say idle is broken, as it is not able to respect utf-8
for print (or even len) of unicode strings.
OTOH, with some tricks I can manage to get an accented a in
a unicode in idle:
>>> import unicodedata
>>> print unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE")
á
>>> print len(unicodedata.lookup("LATIN SMALL LETTER A WITH
ACUTE"))
1
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 17:08
Message:
Logged In: YES
user_id=849994
Using Unicode strings, the OP's example works.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-08-17 17:04
Message:
Logged In: YES
user_id=38388
String upper and lower conversion are locale dependent and
implemented by the underlying libc, whereas Unicode
upper/lower conversion is not and only depends on the
Unicode character database.
OTOH, there are special cases where the standard Unicode
upper/lower mapping is no what you might expect, since the
database only provides a single mapping and is not context
aware.
There's nothing we can do if the libc is broken in some
respect. As for the extended case mapping support in
Unicode: patches are welcome.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 17:03
Message:
Logged In: YES
user_id=849994
sgala: it looks like your console sends UTF-8 encoded text.
>>> print "á"
á
print is just printing out a byte string consisting of two
bytes, which your console displays as accent-a.
>>> print len("á")
2
A UTF-8-encoded string containing an accented a has two bytes.
>>> print "á".upper()
á
str.upper() doesn't take locale into account, so the
accented a has no uppercase version defined.
>>> str("á")
'\xc3\xa1'
str() applied to a byte string returns that byte string.
Since return values from functions are printed by the
interactive interpreter using repr() first, you get this
representation (which you could also get from "print
repr('a')".)
>>> print u"á"
á
That's also okay. Python knows the terminal encoding and
properly translates the byte string to a unicode string of
one character. On printout, it converts it to a UTF-8 string
again, which your terminal displays correctly.
>>> print len(u"á")
1
Since your two-byte-UTF-8 sequence is converted to a unicode
character, the length of this unicode string is 1.
>>> print u"á".upper()
Á
There are comprehensive capitalization tables available for
unicode.
>>> str(u"á")
Traceback (most recent call last):
File "", line 1, in
__builtin__.UnicodeEncodeError: 'ascii' codec
can't encode
character u'\xe1' in position 0: ordinal not in
range(128)
Applying str() to a unicode string must convert it to a byte
string. If you don't specify an encoding, the default
encoding is "ascii", which can't encode the accented a. Use
"a".encode("utf-8").
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-17 16:59
Message:
Logged In: YES
user_id=178886
(I tested it in 2.5rc1), 2.4 gives
>>> str(u"á")
'\xc3\xa1'
instead of the exc
[ python-Bugs-1528802 ] Turkish Character
Bugs item #1528802, was opened at 2006-07-26 07:05
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Ahmet Bişkinler (ahmetbiskinler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Turkish Character
Initial Comment:
>>> print "Mayıs".upper()
>>> MAYıS
>>> import locale
>>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254')
>>> print "Mayıs".upper()
>>> MAYıS
>>> print "ğüşiöçı".upper()
>>> ğüşIöçı
MAYıS should be MAYIS
ğüşIöçı should be ĞÜŞİÖÇI
but
>>> "Mayıs".upper()
>>> "MAYIS"
is right
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 19:08
Message:
Logged In: YES
user_id=849994
Please submit that as a separate IDLE bug.
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-17 18:58
Message:
Logged In: YES
user_id=178886
Idle from 2.5rc1 (svn today) produces a different result
than console (with my default, utf-8, encoding):
IDLE 1.2c1
>>> print "á"
á
>>> print len("á")
2
>>> print "á".upper()
á
>>> str("á")
'\xc3\xa1'
>>> print u"á"
á
>>> print len(u"á")
2
>>> print u"á".upper()
á
>>> str(u"á")
Traceback (most recent call last):
File "", line 1, in
str(u"á")
UnicodeEncodeError: 'ascii' codec can't encode characters in
position 0-1: ordinal not in range(128)
Again, IDLE 1.1.3 (python 2.4.3) produces a different result:
IDLE 1.1.3
>>> print "á"
á
>>> print len("á")
2
>>> print "á".upper()
á
>>> str("á")
'\xc3\xa1'
>>> print u"á"
á
>>> print len(u"á")
2
>>> print u"á".upper()
á
>>> str(u"á")
'\xc3\x83\xc2\xa1'
>>>
I'd say idle is broken, as it is not able to respect utf-8
for print (or even len) of unicode strings.
OTOH, with some tricks I can manage to get an accented a in
a unicode in idle:
>>> import unicodedata
>>> print unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE")
á
>>> print len(unicodedata.lookup("LATIN SMALL LETTER A WITH
ACUTE"))
1
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 15:08
Message:
Logged In: YES
user_id=849994
Using Unicode strings, the OP's example works.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-08-17 15:04
Message:
Logged In: YES
user_id=38388
String upper and lower conversion are locale dependent and
implemented by the underlying libc, whereas Unicode
upper/lower conversion is not and only depends on the
Unicode character database.
OTOH, there are special cases where the standard Unicode
upper/lower mapping is no what you might expect, since the
database only provides a single mapping and is not context
aware.
There's nothing we can do if the libc is broken in some
respect. As for the extended case mapping support in
Unicode: patches are welcome.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 15:03
Message:
Logged In: YES
user_id=849994
sgala: it looks like your console sends UTF-8 encoded text.
>>> print "á"
á
print is just printing out a byte string consisting of two
bytes, which your console displays as accent-a.
>>> print len("á")
2
A UTF-8-encoded string containing an accented a has two bytes.
>>> print "á".upper()
á
str.upper() doesn't take locale into account, so the
accented a has no uppercase version defined.
>>> str("á")
'\xc3\xa1'
str() applied to a byte string returns that byte string.
Since return values from functions are printed by the
interactive interpreter using repr() first, you get this
representation (which you could also get from "print
repr('a')".)
>>> print u"á"
á
That's also okay. Python knows the terminal encoding and
properly translates the byte string to a unicode string of
one character. On printout, it converts it to a UTF-8 string
again, which your terminal displays correctly.
>>> print len(u"á")
1
Since your two-byte-UTF-8 sequence is converted to a unicode
character, the length of this unicode string is 1.
>>> print u"á".upper()
Á
There are comprehensive capitalization tables available for
unicode.
>>> str(u"á")
Traceback (most recent call last):
File "", line 1, in
__builtin__.UnicodeEncodeError: 'ascii' codec
can't encode
character u'\xe1' in position 0: ordinal not in
range(128)
Applying str() to a unicode string must convert it to a byte
string. If you don't specify an encoding, the default
encoding is "ascii", which can't encode the accented a. Use
"a".encode("utf-8").
-
[ python-Bugs-1446043 ] unicode('foo', '.utf99') does not raise LookupError
Bugs item #1446043, was opened at 2006-03-09 00:55
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 8
Submitted By: osvenskan (osvenskan)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: unicode('foo', '.utf99') does not raise LookupError
Initial Comment:
A very minor inconsistency -- when I call unicode()
with an encoding that Python doesn't know about, it
usually returns a lookup error (e.g LookupError:
unknown encoding: utf99). But when the encoding begins
with a dot (ASCII 0x2e), Python instead gives a
ValueError: Empty module name. It is certainly correct
in raising an error, but it should raise a lookup
error, not a value error.
I've recreated this under Python 2.4.1/FreeBSD 6.0 and
2.3/OS X. See attachment for recreation steps.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 19:17
Message:
Logged In: YES
user_id=849994
I'd say that this should be fixed before 2.5 final.
Attached patch (the modname that's used for import may not
contain a dot anymore...)
--
Comment By: osvenskan (osvenskan)
Date: 2006-04-06 14:45
Message:
Logged In: YES
user_id=1119995
I noticed that the documentation for unicode() says, "if the
encoding is not known, LookupError is raised". Regarding the
3rd parameter ("errors") to unicode(), the docs say, "Error
handling is done according to errors; this specifies the
treatment of characters which are invalid in the input
encoding. If errors is 'strict' (the default), a ValueError
is raised on errors..."
ref: http://docs.python.org/lib/built-in-funcs.html
That makes the code's current behavior doubly confusing
because a the documentation says that a ValueError is
reserved for indicating an undecodable byte sequence, not an
unknown encoding name.
--
Comment By: osvenskan (osvenskan)
Date: 2006-03-09 15:04
Message:
Logged In: YES
user_id=1119995
There are encoding names that contain dots, such as
ANSI_X3.4-1968, ANSI_X3.4-1986 and ISO_646.IRV:1991 (as
reported by iconv). There are none in iconv's list that
begin with a dot.
Please note that the behavior of this function has been
discussed before in Python bugs 513666 and 960874. Apologies
for not referencing them in my original report.
Having stepped through the code, I understand how the
ValueError is getting generated. My frustration with this as
a programmer is that I want to write specific except clauses
for each possible exception that a method can raise, but
that's impractical if any exception is fair game on any
method. So I'm forced to use a catch-all except clause about
which the Python documentation says (wisely, IMHO), "Use
this with extreme caution, since it is easy to mask a real
programming error in this way!" While it is helpful to
document errors that a method is *likely* to raise, my code
needs to handle all possibilities, not just likely ones.
Perhaps the answer is just, "This is how Python works" and
if I feel it is a weakness in the language I need to take it
up on a different level.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-09 08:16
Message:
Logged In: YES
user_id=849994
Is it possible for an encoding name to contain dots at all?
If not, this would do too:
if '.' in modname: continue
--
Comment By: Walter Dörwald (doerwalter)
Date: 2006-03-09 08:12
Message:
Logged In: YES
user_id=89016
The problem is that after normalizing the encoding name a
module with this name is imported. Maybe
encodings/__init__.py:search_function should do:
if ".".join(filter(None, modname.split("."))) != modname:
return None
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&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-1541463 ] Optimizations for cgi.FieldStorage methods
Feature Requests item #1541463, was opened at 2006-08-16 13:37
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1541463&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: Bob Kline (bkline)
Assigned to: Georg Brandl (gbrandl)
Summary: Optimizations for cgi.FieldStorage methods
Initial Comment:
Please add the following optimizations to the
FieldStorage class in cgi.py:
# =
def keys(self):
"""Dictionary style keys() method."""
if self.list is None:
raise TypeError, "not indexable"
return {}.fromkeys([item.name for item in
self.list]).keys()
def __nonzero__(self):
"""Support for efficient test of instance"""
return self.list and True or False
# =
The __nonzero__ method is new, and keys() method is a
replacement for code which built the list of unique
fields names by hand, and which took several orders of
magnitude longer to perform.
If you need me to post this as a patch against a
certain version, let me know.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-17 18:52
Message:
Logged In: YES
user_id=764593
Why are you creating a dictionary just to take its keys?
Is there a reason the keys method can't just return
[item.name for item in self.list]
directly?
--
Comment By: Bob Kline (bkline)
Date: 2006-08-16 13:52
Message:
Logged In: YES
user_id=291529
I didn't realize this interface would strip leading blanks
from lines. Patch submitted to get around this problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1541463&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542308 ] Nested finally in generators don't follow PEP 342
Bugs item #1542308, was opened at 2006-08-17 18: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=1542308&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 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Nested finally in generators don't follow PEP 342 Initial Comment: The close() and GC interaction of generators that use yield inside of finally blocks doesn't execute correctly when nested. See the attached example. More information about the issue is in the Mozilla bug tracker (they found a similar bug in their implementation for JS 1.7): https://bugzilla.mozilla.org/show_bug.cgi?id=349012 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&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-1541463 ] Optimizations for cgi.FieldStorage methods
Feature Requests item #1541463, was opened at 2006-08-16 13:37
Message generated for change (Comment added) made by bkline
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1541463&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: Bob Kline (bkline)
Assigned to: Georg Brandl (gbrandl)
Summary: Optimizations for cgi.FieldStorage methods
Initial Comment:
Please add the following optimizations to the
FieldStorage class in cgi.py:
# =
def keys(self):
"""Dictionary style keys() method."""
if self.list is None:
raise TypeError, "not indexable"
return {}.fromkeys([item.name for item in
self.list]).keys()
def __nonzero__(self):
"""Support for efficient test of instance"""
return self.list and True or False
# =
The __nonzero__ method is new, and keys() method is a
replacement for code which built the list of unique
fields names by hand, and which took several orders of
magnitude longer to perform.
If you need me to post this as a patch against a
certain version, let me know.
--
>Comment By: Bob Kline (bkline)
Date: 2006-08-17 19:55
Message:
Logged In: YES
user_id=291529
> Why are you creating a dictionary just to take its keys?
Because in order to preserve the original behavior (and to
match the documentation), the list returned must contain
only one member for each unique field name. The built-in
set() would work just as well, though my benchmarks don't
show much difference in performance. Something like:
return list(set([i.name for i in self.list]))
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-17 18:52
Message:
Logged In: YES
user_id=764593
Why are you creating a dictionary just to take its keys?
Is there a reason the keys method can't just return
[item.name for item in self.list]
directly?
--
Comment By: Bob Kline (bkline)
Date: 2006-08-16 13:52
Message:
Logged In: YES
user_id=291529
I didn't realize this interface would strip leading blanks
from lines. Patch submitted to get around this problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1541463&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542407 ] httplib reads one byte per system call
Bugs item #1542407, was opened at 2006-08-18 00: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=1542407&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Zoyd Wheeler (zoyd2k)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib reads one byte per system call
Initial Comment:
The HTTPResponse class in httplib.py contains the
following line in its __init__ method:
self.fp = sock.makefile('rb', 0)
The zero in that second (bufsize) argument overrides
the default behavior of the socket filedescriptor in
its readline() method, which is to read in a buffer's
worth of data from the socket at a time and only hit
the socket again if the buffer runs dry. When bufsize
is set to zero, the filedescriptor sets its internal
buffer size to one. As a result, readline() makes a
system call for every byte of data consumed. Since
httplib uses readline to obtain the http header, that's
an awful lot of system calls. We noticed this when
trying to build a fairly aggressive application on top
of xmlrpclib (which relies on httplib); we saw tons of
system call activity.
There is no comment near this line of code to indicate
whether this behavior is intended or not. If it is not
intended, the patch is to simply remove the second
argument and rely on the default (or allow the caller
to specify a buffer size).
In case reading a byte at a time is actually intended,
we have a simple work-around for those who care to use
it. In the python code that uses httplib, add the
following:
import httplib
...
class HTTPResponse(httplib.HTTPResponse):
def __init__(self, sock, **kw):
httplib.HTTPResponse.__init__(self, sock, **kw)
self.fp = sock.makefile('rb')
httplib.HTTPConnection.response_class = HTTPResponse
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542407&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1541697 ] Recently introduced sgmllib regexp bug hangs Python
Bugs item #1541697, was opened at 2006-08-17 10:51
Message generated for change (Comment added) made by quiver
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&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: 8
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Recently introduced sgmllib regexp bug hangs Python
Initial Comment:
Looks like revision 47154 introduced a regexp that
hangs Python (Ctrl-C won't kill the process, CPU usage
sits near 100%) under some circumstances. A test case
is attached (sgmllib.html and hang_sgmllib.py).
The problem isn't seen if you read the whole file (or
nearly the whole file) at once. But that doesn't make
it a non-bug, AFAICS.
I'm not sure what the problem is, but presumably the
relevant part of the patch is this:
+starttag = re.compile(r'<[a-zA-Z][-_.:a-zA-Z0-9]*\s*('
+r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=\s*'
+
r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)[EMAIL PROTECTED]'
+
r'[][\-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~\'"@]*(?=[\s>/<])))?'
+r')*\s*/?\s*(?=[<>])')
The patch attached to bug 1515142 (also from Sam Ruby
-- claims to fix a regression introduced by his recent
sgmllib patches, and has not yet been applied) does NOT
fix the problem.
--
>Comment By: George Yoshida (quiver)
Date: 2006-08-18 13:55
Message:
Logged In: YES
user_id=671362
Slimmed down test case is attached.(The regex pattern in
question is used)
FYI, r47154 is backported to 2.4 branch(r47155).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542432 ] python-2.5c1.msi contains ICE validation errors and warnings
Bugs item #1542432, was opened at 2006-08-18 06:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542432&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Arnson (barnson) Assigned to: Nobody/Anonymous (nobody) Summary: python-2.5c1.msi contains ICE validation errors and warnings Initial Comment: python-2.5c1.msi contains the following ICE validation errors and warnings: ICE21 ERROR Component: 'REGISTRY.tcl' does not belong to any Feature. === REGISTRY.tcl is still getting installed but it should be listed in FeatureComponents. ICE57 WARNING Component 'REGISTRY.def' has a registry entry that can be either per-user or per-machine and a per-machine KeyPath. ICE57 ERROR Component 'REGISTRY.doc' has both per-user data and a keypath that can be either per-user or per-machine. ICE57 ERROR Component 'REGISTRY' has both per-user data and a keypath that can be either per-user or per-machine. === I think you can fix all these by using an appropriate registry entry as the KeyPath. ICE67 WARNING The shortcut 'Manual' is a non-advertised shortcut with a file target. The shortcut and target are installed by different components, and the target component can run locally or from source. ICE69 WARNING Mismatched component reference. Entry 'Manual' of the Shortcut table belongs to component 'REGISTRY.doc'. However, the formatted string in column 'Target' references file 'Python25.chm' which belongs to component 'documentation'. Components are in the same feature. === These are fairly benign, but you can clean them up if you want by moving the shortcut into the "documentation" component. (The idea is that related resources [files, registry values, shortcuts] live in the same component, so when one is installed, all are installed atomically.) You can run validation from Orca or the MsiVal2, both of which are in the Platform/Windows SDK. Details about ICEs are available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/ice_reference.asp. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542432&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542432 ] python-2.5c1.msi contains ICE validation errors and warnings
Bugs item #1542432, was opened at 2006-08-18 08:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542432&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Arnson (barnson) Assigned to: Nobody/Anonymous (nobody) Summary: python-2.5c1.msi contains ICE validation errors and warnings Initial Comment: python-2.5c1.msi contains the following ICE validation errors and warnings: ICE21 ERROR Component: 'REGISTRY.tcl' does not belong to any Feature. === REGISTRY.tcl is still getting installed but it should be listed in FeatureComponents. ICE57 WARNING Component 'REGISTRY.def' has a registry entry that can be either per-user or per-machine and a per-machine KeyPath. ICE57 ERROR Component 'REGISTRY.doc' has both per-user data and a keypath that can be either per-user or per-machine. ICE57 ERROR Component 'REGISTRY' has both per-user data and a keypath that can be either per-user or per-machine. === I think you can fix all these by using an appropriate registry entry as the KeyPath. ICE67 WARNING The shortcut 'Manual' is a non-advertised shortcut with a file target. The shortcut and target are installed by different components, and the target component can run locally or from source. ICE69 WARNING Mismatched component reference. Entry 'Manual' of the Shortcut table belongs to component 'REGISTRY.doc'. However, the formatted string in column 'Target' references file 'Python25.chm' which belongs to component 'documentation'. Components are in the same feature. === These are fairly benign, but you can clean them up if you want by moving the shortcut into the "documentation" component. (The idea is that related resources [files, registry values, shortcuts] live in the same component, so when one is installed, all are installed atomically.) You can run validation from Orca or the MsiVal2, both of which are in the Platform/Windows SDK. Details about ICEs are available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/ice_reference.asp. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-08-18 08:53 Message: Logged In: YES user_id=21627 These validation errors existed ever since Python 2.4. Is there an actual problem? I could not find a way to fix them, and believe some of the ICEs are broken. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542432&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
