[ python-Bugs-1503883 ] csv.Sniffer - says "1 method", shows 2
Bugs item #1503883, was opened at 2006-06-10 07: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=1503883&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frank Millman (frankmillman) Assigned to: Nobody/Anonymous (nobody) Summary: csv.Sniffer - says "1 method", shows 2 Initial Comment: >From the csv module - - class Sniffer( ) [...] The Sniffer class provides a single method: [...] sniff( sample[,delimiters=None]) [...] has_header( sample) [...] - It says "provides a single method", and then shows two methods. One is not sure whether "has_header" is part of Sniffer or not. Frank Millman -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503883&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503883 ] csv.Sniffer - says "1 method", shows 2
Bugs item #1503883, was opened at 2006-06-10 07:33 Message generated for change (Comment added) made by frankmillman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503883&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Frank Millman (frankmillman) Assigned to: Nobody/Anonymous (nobody) Summary: csv.Sniffer - says "1 method", shows 2 Initial Comment: >From the csv module - - class Sniffer( ) [...] The Sniffer class provides a single method: [...] sniff( sample[,delimiters=None]) [...] has_header( sample) [...] - It says "provides a single method", and then shows two methods. One is not sure whether "has_header" is part of Sniffer or not. Frank Millman -- >Comment By: Frank Millman (frankmillman) Date: 2006-06-10 09:10 Message: Logged In: YES user_id=1070042 Apologies - I see this has been fixed in 2.5 Frank -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503883&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1496501 ] tarfile.py: dict order dependency
Bugs item #1496501, was opened at 2006-05-28 18:42
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.py: dict order dependency
Initial Comment:
When guessing the type of a file, tarfile.py tries to
open it in .tar, .tar.gz and .tar.bz2 modes
successfully. The problem is that in conjunction with a
fileobj argument, failed attempts can advance the
current position of the fileobj, and cause the following
attempts to fail as well.
This didn't show up so far because, by chance, the order
in which the OPEN_METH dictionary is enumerated is
somehow the "correct" one. The problem can be seen by
changing this order and re-running test_tarfile.py; for
example, reverse the order (tarfile.py line 1013):
for comptype in reversed(cls.OPEN_METH):
--
>Comment By: Armin Rigo (arigo)
Date: 2006-06-10 10:46
Message:
Logged In: YES
user_id=4771
If possible, I would prefer that the constructors were fixed
to become order-independent. Not sure how easy this is,
though.
--
Comment By: Jack Diederich (jackdied)
Date: 2006-06-09 19:56
Message:
Logged In: YES
user_id=591932
I took a look at tarfile.py and though there is this comment
about OPEN_METH
# This concept allows one to subclass TarFile without losing
the comfort of
# the super-constructor. A sub-constructor is registered and
made available
# by adding it to the mapping in OPEN_METH.
because adding items to OPEN_METH could change the order and
break the Tarfile.open() classmethod I doubt adding to
OPEN_METH is done in practice.
+1 for renaming OPEN_METH to _OPEN_METH and making it a list
of two-tuples.
+0 on changing the two tups from ('typename', 'funcname') to
('typename', function_ref) and dropping the getattr
functionality. The three default openers are not listed in
the public interface so if anyone is subclassing Tarfile and
overriding them (doubtful) they are doing so at their own peril.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503294 ] -Wi causes a fatal Python error
Bugs item #1503294, was opened at 2006-06-09 03:20 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&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: Closed >Resolution: Fixed Priority: 8 Submitted By: Brett Cannon (bcannon) Assigned to: Armin Rigo (arigo) Summary: -Wi causes a fatal Python error Initial Comment: PYTHONPATH=/Users/drifty/Code/Compiled/lib/python2.5 \ ./python.exe -Wi -tt /Users/drifty/Code/Compiled/lib/python2.5/compileall.py \ -d /Users/drifty/Code/Compiled/lib/python2.5 -f \ -x 'bad_coding|badsyntax|site-packages' /Users/drifty/Code/Compiled/lib/python2.5 Fatal Python error: PyThreadState_Get: no current thread make: *** [libinstall] Abort trap Works if I remove ``-Wi -tt`` from the command. -- >Comment By: Armin Rigo (arigo) Date: 2006-06-10 10:59 Message: Logged In: YES user_id=4771 Ah, PyThreadState_GET() complains if tstate is NULL, but only in debug mode. My code was prepared to handle a NULL return value; I didn't expect this extra check :-) Let's read _PyThreadState_Current directly then, as I don't see another way to get at it with no check. Checked in as r46818. Command-line arguments are not too much stressed by the test suite... -- Comment By: Brett Cannon (bcannon) Date: 2006-06-10 02:54 Message: Logged In: YES user_id=357491 Ah-ha! I checked svn blame on PyThreadState_Get() and PyThreadState_GET(), but not on PyDict_GetItem(). Assigning to Armin since he caused this ruckus. =) -- Comment By: Tim Peters (tim_one) Date: 2006-06-10 02:19 Message: Logged In: YES user_id=31435 Removed "on OS X" from the Summary line, since this is trivial to reproduce on Windows too: $ python_d -Wi Fatal Python error: PyThreadState_Get: no current thread Note that I used a debug build there; the error doesn't occur if I use a release build instead. As a matter of fact, Armin recently added a comment to dictobject.c pointing out this very failure mode: /* We can arrive here with a NULL tstate during initialization: try running "python -Wi" for an example related to string interning. Let's just hope that no exception occurs then... */ For that matter, it could be that Armin _created_ this failure mode too ;-) -- Comment By: Brett Cannon (bcannon) Date: 2006-06-10 01:42 Message: Logged In: YES user_id=357491 OK, so -Wi is causing the failure. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-09 16:59 Message: Logged In: YES user_id=357491 Forgot to try this with just one of the two flags; will do that soon. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503789 ] Cannot write source code in UTF16
Bugs item #1503789, was opened at 2006-06-10 02:38 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot write source code in UTF16 Initial Comment: I intend to create some source code in UTF16. I start the file with the encoding declaration line: -- # -*- coding: UTF-16LE -*- print "Hello world" -- Unfortunately Python does not decode it in UTF16 as expected. I have found some language in PEP 0263 that says "It does not include encodings which use two or more bytes for all characters like e.g. UTF-16." While I am disappointed. I accepted this limitation is necessary to make keep the parser simple. So my first complaint is this fact should be documented in http://www.python.org/doc/ref/encodings.html Then I tried to save the source code with BOM. I think there should be no excuse not to decode it in UTF16 in that case. Unfortunately Python does not support this either. Indeed the only way to get it work is to write the encoding declaration line in ASCII and the rest of the file in UTF16 (see u16_hybrid.py). Obviously most text editor would not support this. I come up with this because Microsoft adopt UTF16 in various places. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-06-10 14:27 Message: Logged In: YES user_id=21627 Would you like to work on a patch? There is, of course, a fairly obvious reason that this doesn't work: nobody has put effort into making it work. Personally, I suggest that you use some other encoding for source code, e.g. UTF-8. -- Comment By: Wai Yip Tung (tungwaiyip) Date: 2006-06-10 02:39 Message: Logged In: YES user_id=561546 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503883 ] csv.Sniffer - says "1 method", shows 2
Bugs item #1503883, was opened at 2006-06-10 02:33 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503883&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Frank Millman (frankmillman) Assigned to: Nobody/Anonymous (nobody) Summary: csv.Sniffer - says "1 method", shows 2 Initial Comment: >From the csv module - - class Sniffer( ) [...] The Sniffer class provides a single method: [...] sniff( sample[,delimiters=None]) [...] has_header( sample) [...] - It says "provides a single method", and then shows two methods. One is not sure whether "has_header" is part of Sniffer or not. Frank Millman -- >Comment By: Skip Montanaro (montanaro) Date: 2006-06-10 09:03 Message: Logged In: YES user_id=44345 Nevertheless, this change should have been backported. Thanks for the catch. I'll have the correction to the 2.4 branch checked in momentarily. Skip -- Comment By: Frank Millman (frankmillman) Date: 2006-06-10 04:10 Message: Logged In: YES user_id=1070042 Apologies - I see this has been fixed in 2.5 Frank -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503883&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1449311 ] optparse: extending actions missing ALWAYS_TYPED_ACTIONS
Bugs item #1449311, was opened at 2006-03-13 21:07
Message generated for change (Settings changed) made by gward
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1449311&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher (chrism1)
>Assigned to: Greg Ward (gward)
>Summary: optparse: extending actions missing ALWAYS_TYPED_ACTIONS
Initial Comment:
http://docs.python.org/lib/optparse-adding-new-actions.
html
This page of docs should include the ALWAYS_TYPED_
ACTIONS list from optparse.py. In the example, unless
you add the following line:
ALWAYS_TYPED_ACTIONS = Option.ALWAYS_TYPED_ACTIONS
+ ("dict",)
, then the "Value" variable gets no value unless you
explicitly pass "type='string'" to parser.add_option().
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1449311&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1496501 ] tarfile.py: dict order dependency
Bugs item #1496501, was opened at 2006-05-28 14:42
Message generated for change (Comment added) made by jackdied
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.py: dict order dependency
Initial Comment:
When guessing the type of a file, tarfile.py tries to
open it in .tar, .tar.gz and .tar.bz2 modes
successfully. The problem is that in conjunction with a
fileobj argument, failed attempts can advance the
current position of the fileobj, and cause the following
attempts to fail as well.
This didn't show up so far because, by chance, the order
in which the OPEN_METH dictionary is enumerated is
somehow the "correct" one. The problem can be seen by
changing this order and re-running test_tarfile.py; for
example, reverse the order (tarfile.py line 1013):
for comptype in reversed(cls.OPEN_METH):
--
Comment By: Jack Diederich (jackdied)
Date: 2006-06-10 12:15
Message:
Logged In: YES
user_id=591932
The invidual openers could tell() the fileobj and revert
with a seek() on failure. The module requires those methods
be implemented already to work so that is safe. I'll cook
up a patch.
But basically open() isn't as extensible as it seems.
Stream reading and writing isn't supported for injected
compression types and appending only works on plain tarfiles.
I'm guessing that isn't a problem in practice or someone
would have mentioned it by now ;)
--
Comment By: Armin Rigo (arigo)
Date: 2006-06-10 06:46
Message:
Logged In: YES
user_id=4771
If possible, I would prefer that the constructors were fixed
to become order-independent. Not sure how easy this is,
though.
--
Comment By: Jack Diederich (jackdied)
Date: 2006-06-09 15:56
Message:
Logged In: YES
user_id=591932
I took a look at tarfile.py and though there is this comment
about OPEN_METH
# This concept allows one to subclass TarFile without losing
the comfort of
# the super-constructor. A sub-constructor is registered and
made available
# by adding it to the mapping in OPEN_METH.
because adding items to OPEN_METH could change the order and
break the Tarfile.open() classmethod I doubt adding to
OPEN_METH is done in practice.
+1 for renaming OPEN_METH to _OPEN_METH and making it a list
of two-tuples.
+0 on changing the two tups from ('typename', 'funcname') to
('typename', function_ref) and dropping the getattr
functionality. The three default openers are not listed in
the public interface so if anyone is subclassing Tarfile and
overriding them (doubtful) they are doing so at their own peril.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1449311 ] optparse: extending actions missing ALWAYS_TYPED_ACTIONS
Bugs item #1449311, was opened at 2006-03-13 21:07
Message generated for change (Comment added) made by gward
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1449311&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher (chrism1)
Assigned to: Greg Ward (gward)
Summary: optparse: extending actions missing ALWAYS_TYPED_ACTIONS
Initial Comment:
http://docs.python.org/lib/optparse-adding-new-actions.
html
This page of docs should include the ALWAYS_TYPED_
ACTIONS list from optparse.py. In the example, unless
you add the following line:
ALWAYS_TYPED_ACTIONS = Option.ALWAYS_TYPED_ACTIONS
+ ("dict",)
, then the "Value" variable gets no value unless you
explicitly pass "type='string'" to parser.add_option().
--
>Comment By: Greg Ward (gward)
Date: 2006-06-10 12:40
Message:
Logged In: YES
user_id=14422
Oops! Quite right. Thanks for catching this.
This is actually a bug in Optik's documentation, so the real
fix is there (rev 517 of Optik svn).
Fixed in Python svn: rev 46821 (Doc/lib/liboptparse.tex).
This is trunk (Python 2.5) only.
(BTW, you forgot to mention which example had this error.
Also, the new action in the example is "extend", not
"dict". This would have been a bit quicker and easier to
fix if those details had been there.)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1449311&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1449311 ] optparse: extending actions missing ALWAYS_TYPED_ACTIONS
Bugs item #1449311, was opened at 2006-03-13 21:07
Message generated for change (Settings changed) made by gward
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1449311&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christopher (chrism1)
Assigned to: Greg Ward (gward)
Summary: optparse: extending actions missing ALWAYS_TYPED_ACTIONS
Initial Comment:
http://docs.python.org/lib/optparse-adding-new-actions.
html
This page of docs should include the ALWAYS_TYPED_
ACTIONS list from optparse.py. In the example, unless
you add the following line:
ALWAYS_TYPED_ACTIONS = Option.ALWAYS_TYPED_ACTIONS
+ ("dict",)
, then the "Value" variable gets no value unless you
explicitly pass "type='string'" to parser.add_option().
--
Comment By: Greg Ward (gward)
Date: 2006-06-10 12:40
Message:
Logged In: YES
user_id=14422
Oops! Quite right. Thanks for catching this.
This is actually a bug in Optik's documentation, so the real
fix is there (rev 517 of Optik svn).
Fixed in Python svn: rev 46821 (Doc/lib/liboptparse.tex).
This is trunk (Python 2.5) only.
(BTW, you forgot to mention which example had this error.
Also, the new action in the example is "extend", not
"dict". This would have been a bit quicker and easier to
fix if those details had been there.)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1449311&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1183972 ] dest parameter in optparse
Bugs item #1183972, was opened at 2005-04-15 15:39 Message generated for change (Settings changed) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183972&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.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: ahmado (ahmado) Assigned to: Greg Ward (gward) Summary: dest parameter in optparse Initial Comment: When using the "callback" action, optparse requires that you STILL specify a "dest" parameter, though it is not required or used by the option parser. In fact, if you do not include the "dest" parameter, your options will still work properly, but optparse will generate an exception when calling the "--help" option. Not specifying a "dest" parameter will result in the following Exception when using the default "--help" or "- h" option: File "c:\Python23\lib\optparse.py", line 229, in format_option_strings metavar = option.metavar or option.dest.upper() AttributeError: 'NoneType' object has no attribute 'upper' by simply adding a bogus bug, the --help / -h option works properly even though the dest isn't actually used. -- >Comment By: Greg Ward (gward) Date: 2006-06-10 12:42 Message: Logged In: YES user_id=14422 No response from original poster after almost a year, so I'm assuming that I did indeed fix this bug in Optik 1.5 / Python 2.4. -- Comment By: Greg Ward (gward) Date: 2005-08-09 20:57 Message: Logged In: YES user_id=14422 ahmado -- please check if this bug is still present in Python 2.4 / Optik 1.5. If you do not respond in a week or two, I will assume that the bug is fixed and close this report. -- Comment By: Greg Ward (gward) Date: 2005-07-21 22:03 Message: Logged In: YES user_id=14422 I'm pretty sure I fixed this in Optik 1.5 / Python 2.4. Can you 1) verify if the bug is still there in Python 2.4 and 2) if so, supply a small script demonstrating the problem? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183972&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1496501 ] tarfile.py: dict order dependency
Bugs item #1496501, was opened at 2006-05-28 14:42
Message generated for change (Comment added) made by jackdied
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.py: dict order dependency
Initial Comment:
When guessing the type of a file, tarfile.py tries to
open it in .tar, .tar.gz and .tar.bz2 modes
successfully. The problem is that in conjunction with a
fileobj argument, failed attempts can advance the
current position of the fileobj, and cause the following
attempts to fail as well.
This didn't show up so far because, by chance, the order
in which the OPEN_METH dictionary is enumerated is
somehow the "correct" one. The problem can be seen by
changing this order and re-running test_tarfile.py; for
example, reverse the order (tarfile.py line 1013):
for comptype in reversed(cls.OPEN_METH):
--
Comment By: Jack Diederich (jackdied)
Date: 2006-06-10 13:46
Message:
Logged In: YES
user_id=591932
added patch 1504073 because SF won't let just anyone attach
files to bugs.
--
Comment By: Jack Diederich (jackdied)
Date: 2006-06-10 12:15
Message:
Logged In: YES
user_id=591932
The invidual openers could tell() the fileobj and revert
with a seek() on failure. The module requires those methods
be implemented already to work so that is safe. I'll cook
up a patch.
But basically open() isn't as extensible as it seems.
Stream reading and writing isn't supported for injected
compression types and appending only works on plain tarfiles.
I'm guessing that isn't a problem in practice or someone
would have mentioned it by now ;)
--
Comment By: Armin Rigo (arigo)
Date: 2006-06-10 06:46
Message:
Logged In: YES
user_id=4771
If possible, I would prefer that the constructors were fixed
to become order-independent. Not sure how easy this is,
though.
--
Comment By: Jack Diederich (jackdied)
Date: 2006-06-09 15:56
Message:
Logged In: YES
user_id=591932
I took a look at tarfile.py and though there is this comment
about OPEN_METH
# This concept allows one to subclass TarFile without losing
the comfort of
# the super-constructor. A sub-constructor is registered and
made available
# by adding it to the mapping in OPEN_METH.
because adding items to OPEN_METH could change the order and
break the Tarfile.open() classmethod I doubt adding to
OPEN_METH is done in practice.
+1 for renaming OPEN_METH to _OPEN_METH and making it a list
of two-tuples.
+0 on changing the two tups from ('typename', 'funcname') to
('typename', function_ref) and dropping the getattr
functionality. The three default openers are not listed in
the public interface so if anyone is subclassing Tarfile and
overriding them (doubtful) they are doing so at their own peril.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1417699 ] float/atof have become locale aware
Bugs item #1417699, was opened at 2006-01-29 02:04
Message generated for change (Comment added) made by bernhard
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&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: 7
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Nobody/Anonymous (nobody)
Summary: float/atof have become locale aware
Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:
Python 2.4.2 (#1, Nov 29 2005, 16:07:55)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5
This doesn't match what's specified in pep 331:
- float() and str() stay locale-unaware.
It also doesn't match the documentation for atof:
Convert a string to a floating point number.
The string must have the standard syntax for a
floating point literal in Python, optionally
preceded by a sign ("+" or "-"). Note that this
behaves identical to the built-in function float()
when passed a string.
The documentation for float() doesn't state which
format is accepted by float(), though.
The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:
This function behaves like the standard strtod()
function does in the C locale.
--
>Comment By: Bernhard Herzog (bernhard)
Date: 2006-06-10 21:18
Message:
Logged In: YES
user_id=2369
gustavo, your patch seems to work fine. However, it leads
to some test failures because the testsuite already tests
for the wrong behaviour. I've uploaded a version of your
patch that in addtion to your changes contains modifications
to the test suite so that it tests for the new behavior and
also tests some more variations of floating point literals
accepted by float().
It would be nice if this patch could go into 2.5 before beta1
--
Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-16 18:35
Message:
Logged In: YES
user_id=908
It seems I can't upload files?!
I have put the patch to fix this problem, including unit
test, here: http://www.gnome.org/~gjc/python-1417699.diff
--
Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-13 13:59
Message:
Logged In: YES
user_id=908
I'm quite busy at this moment, but I'll send a patch soon,
promise.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-05-12 16:14
Message:
Logged In: YES
user_id=21627
Unassigning myself - I don't plan to work on this anytime soon.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-05-08 20:00
Message:
Logged In: YES
user_id=849994
I grepped around and found PyOS_ascii_strtod in the
following places:
* stropmodule::atof
* cPickle::load_float (the writing of locale dependent
floats was fixed recently)
* floatobject::PyFloat_FromString
* complexobject::complex_subtype_from_string
In my opinion, all these should not tolerate localized
floats, so Gustavo, please ask the original author how to
achieve this.
--
Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-04 11:47
Message:
Logged In: YES
user_id=908
My comment is, is "PyOS_ascii_strtod accepting both forms"
something that is harmful and should be fixed?
I didn't exactly write the PyOS_ascii_strtod code; I only
integrated it with Python. But if we really need to fix
this, I'll try to figure out how to make it not accept
floating points in locale aware format; if necessary I'll
ask help from the original author of the code, Alexander
Larsson.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-05-04 06:42
Message:
Logged In: YES
user_id=21627
It's a bug. As bernhard says, it originates from
PyOS_ascii_strtod accepting both forms, which in turn
happens because it just leaves the locale-specific decimal
point in the string, only replacing the . with the
locale-specific point. Then, the platform's strtod will
happily accept the locale-specific version.
I'd like Gustavo Carneiro to comment.
--
[ python-Bugs-1361643 ] textwrap.dedent() expands tabs
Bugs item #1361643, was opened at 2005-11-19 14:02
Message generated for change (Comment added) made by gward
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Library
>Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Steven Bethard (bediviere)
Assigned to: Greg Ward (gward)
Summary: textwrap.dedent() expands tabs
Initial Comment:
I'm not sure whether this is a documentation bug or a
code bug, but textwrap.dedent() expands tabs (and
AFAICT doesn't give the user any way of stopping this):
py> def test():
... x = ('abcdefgh\n'
... 'ijklmnop\n')
... y = textwrap.dedent('''\
... abcdefgh
... ijklmnop
... ''')
... return x, y
...
py> test()
('abcd\tefgh\nijkl\tmnop\n', 'abcdefgh\nijkl
mnop\n')
Looking at the code, I can see the culprit is the first
line:
lines = text.expandtabs().split('\n')
If this is the intended behavior, I think the first
sentence in the documentation[1] should be replaced with:
"""
Replace all tabs in string with spaces as per
str.expandtabs() and then remove any whitespace that
can be uniformly removed from the left of every line in
text.
"""
and (I guess this part is an RFE) textwrap.dedent()
should gain an optional expandtabs= keyword argument to
disable this behavior.
If it's not the intended behavior, I'd love to see that
.expandtabs() call removed.
[1]http://docs.python.org/lib/module-textwrap.html
--
>Comment By: Greg Ward (gward)
Date: 2006-06-10 20:41
Message:
Logged In: YES
user_id=14422
I agree that the docs are (pretty) clear and the code is
wrong. When determining common leading whitespace, tabs and
spaces should *not* be treated as equivalent.
Raymond's fix was close, but not quite there: considering
only the length of leading whitespace still causes space/tab
confusion. (This only became clear to me after I wrote
several test cases.)
My fix is based on Raymond's, i.e. it uses regexes for most
of the heavy lifting rather than splitting the input string
on newline and looping over the lines. The bit that's
different is determining what exactly is the common leading
whitespace string. Anyways, this ended up being a complete
rewrite of dedent(). I also added a paragraph to the docs
to clarify the distinction between tabs and spaces.
Checked in under rev 46844 (trunk only).
--
Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-15 03:45
Message:
Logged In: YES
user_id=1188172
Looks good!
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-11-20 01:04
Message:
Logged In: YES
user_id=80475
Suggested code:
import re as _re
_emptylines_with_spaces = _re.compile('(?m)^[ \t]+$')
_prefixes_on_nonempty_lines = _re.compile('(?m)(^[
\t]*)(?:[^ \t\n]+)')
def dedent(text):
text = _emptylines_with_spaces.sub('', text)
prefixes = _prefixes_on_nonempty_lines.findall(text)
margin = min(prefixes or [''])
if margin:
text = _re.sub('(?m)^' + margin, '', text)
return text
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-11-19 23:52
Message:
Logged In: YES
user_id=80475
After more thought, I think the expandtabs() is a bug since
it expands content tabs as well as margin tabs:
>>> textwrap.dedent('\tABC\t\tDEF')
'ABC DEF'
This is especially problematic given that dedent() has to
guess at the tab size.
If this gets fixed, I recommend using regular expressions as
a way to indentify common margin prefixes on non-empty
lines. This will also mixes of spaces and tabs without
altering content with embedded tabs and without making
assumptions about the tab size. Also, it ought to run
somewhat faster.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-11-19 15:18
Message:
Logged In: YES
user_id=80475
FWIW, the tab expansion would be more useful if the default
tabsize could be changed.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
