[ python-Bugs-1193061 ] Python and Turkish Locale
Bugs item #1193061, was opened at 2005-04-30 19:37 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193061&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: S.Çağlar Onur (caglar) Assigned to: M.-A. Lemburg (lemburg) Summary: Python and Turkish Locale Initial Comment: On behalf of this thread; http://mail.python.org/pipermail/python-dev/2005-April/052968.html As described in http://www.i18nguy.com/unicode/turkish-i18n.html [ How Applications Fail With Turkish Language ] , Turkish has 4 "i" in their alphabet. Without --with-wctype-functions support Python convert these characters locare-independent manner in tr_TR.UTF-8 locale. So all conversitons maps to "i" or "I" which is wrong in Turkish locale. So if Python Developers will remove the wctype functions from Python, then there must be a locale-dependent upper/lower funtion to handle these characters properly. -- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-02 10:00 Message: Logged In: YES user_id=38388 I'm not sure I understand: are you saying that the Unicode mappings for upper and lower case are wrong in the standard ? Note that removing the wctype functions will only remove the possibility to use these functions for case mapping of Unicode characters instead of using the builtin Unicode character database. This was originally meant as optimization to avoid having to load the Unicode database - nowadays the database is always included, so the optimization is no longer needed. Even worse: the wctype functions sometimes behave differently than the mappings in the Unicode database (due to differences in the Unicode database version or implementation s). Now, since the string .lower() and .upper() methods are locale dependent (due to their reliance on the C functions toupper() and tolower() - not by intent), while the Unicode versions are not, we have a rather annoying situation where switching from strings to Unicode cause semantic differences. Ideally, both string and Unicode methods should do case mapping in an locale independent way. The support for differences in locale dependent case mapping, collation, etc. should be moved to an external module, e.g. the locale module. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193061&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1193061 ] Python and Turkish Locale
Bugs item #1193061, was opened at 2005-04-30 20:37 Message generated for change (Comment added) made by caglar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193061&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: S.Çağlar Onur (caglar) Assigned to: M.-A. Lemburg (lemburg) Summary: Python and Turkish Locale Initial Comment: On behalf of this thread; http://mail.python.org/pipermail/python-dev/2005-April/052968.html As described in http://www.i18nguy.com/unicode/turkish-i18n.html [ How Applications Fail With Turkish Language ] , Turkish has 4 "i" in their alphabet. Without --with-wctype-functions support Python convert these characters locare-independent manner in tr_TR.UTF-8 locale. So all conversitons maps to "i" or "I" which is wrong in Turkish locale. So if Python Developers will remove the wctype functions from Python, then there must be a locale-dependent upper/lower funtion to handle these characters properly. -- >Comment By: S.Çağlar Onur (caglar) Date: 2005-05-02 11:45 Message: Logged In: YES user_id=858447 No, im not. These rules defined in http://www.unicode.org/Public/UNIDATA/CaseFolding.txt and http://www.unicode.org/Public/UNIDATA/SpecialCasing.txt. Note that there is a comments says; # T: special case for uppercase I and dotted uppercase I #- For non-Turkic languages, this mapping is normally not used. #- For Turkic languages (tr, az), this mapping can be used instead of the normal mapping for these characters. # Note that the Turkic mappings do not maintain canonical equivalence without additional processing. # See the discussions of case mapping in the Unicode Standard for more information. So without wctype functions support, python can't convert these. This _is_ the problem. As a side effect of this, another huge problem occurs, keywords can't be locale dependent. If Python compiled with wctype support functions, all "i".upper() turns into "İ" which is wrong for keyword comparision ( like quit v.s QUİT ) So i suggest implement two new functions like localeAwareLower()/localeAwareUpper() for python and let lower()/upper() locale independent. And as you wrote locale module may be a perfect home for these :) -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-02 11:00 Message: Logged In: YES user_id=38388 I'm not sure I understand: are you saying that the Unicode mappings for upper and lower case are wrong in the standard ? Note that removing the wctype functions will only remove the possibility to use these functions for case mapping of Unicode characters instead of using the builtin Unicode character database. This was originally meant as optimization to avoid having to load the Unicode database - nowadays the database is always included, so the optimization is no longer needed. Even worse: the wctype functions sometimes behave differently than the mappings in the Unicode database (due to differences in the Unicode database version or implementation s). Now, since the string .lower() and .upper() methods are locale dependent (due to their reliance on the C functions toupper() and tolower() - not by intent), while the Unicode versions are not, we have a rather annoying situation where switching from strings to Unicode cause semantic differences. Ideally, both string and Unicode methods should do case mapping in an locale independent way. The support for differences in locale dependent case mapping, collation, etc. should be moved to an external module, e.g. the locale module. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193061&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1192554 ] doctest's ELLIPSIS and multiline statements
Bugs item #1192554, was opened at 2005-04-29 19:36
Message generated for change (Settings changed) made by boisgerault
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192554&group_id=5470
Category: Python Library
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Sébastien Boisgérault (boisgerault)
Assigned to: Nobody/Anonymous (nobody)
Summary: doctest's ELLIPSIS and multiline statements
Initial Comment:
The doctest ELLPSIS marker (default: "...") may be
confused by the doctest parser with the multiline
statement marker ("...").
Example: in the following code, the intent was to accept
any result after "print 42". This is NOT a multiline
statement,
but however the test fails (Expected: nothing, Got: 42).
#!/usr/bin/env python
import doctest
def test():
"""
>>> print 42 #doctest: +ELLIPSIS
...
"""
def run():
"Run the test."
doctest.testmod()
if __name__ == '__main__':
run()
--
Comment By: Tim Peters (tim_one)
Date: 2005-04-29 19:52
Message:
Logged In: YES
user_id=31435
That's true. doctest has few syntax requirements, but the
inability to start an expected output block with "..." has
always been one of them, and is independent of the
ELLIPSIS gimmick. I doubt this will change, in part because
the complications needed to "do something about it" are
probably pig ugly, in part because it's so rare a desire, and in
part because there are easy ways to work around it (like
arranging for the expected output to start with something
other than '...').
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192554&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1193180 ] Strange os.path.exists() results with invalid chars
Bugs item #1193180, was opened at 2005-05-01 01:13
Message generated for change (Comment added) made by zgoda
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&group_id=5470
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniele Varrazzo (dvarrazzo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange os.path.exists() results with invalid chars
Initial Comment:
Hi,
when there are invalid chars in a filename, os.path.exists
() behaves oddly, returning True.
The bug appears on win32 system, not on unix ones.
Thus is probably related to some weird windows api call
and doesn't maybe worth fixing.
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import os
>>> f = file("a_b", "w")
>>> f.close()
>>> os.listdir(".")
['a_b']
>>> os.path.exists("a>> os.path.exists("a>b")
True
And, even more strange...
>>> os.path.exists("a<")
True
>>> os.path.exists("a>")
False
Better answers would have been:
* False
* raise ValueError
--
Comment By: Jarek Zgoda (zgoda)
Date: 2005-05-02 14:04
Message:
Logged In: YES
user_id=9
Same for Python 2.3.5.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1193849 ] os.path.expanduser documentation wrt. empty $HOME
Bugs item #1193849, was opened at 2005-05-02 17:02
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=1193849&group_id=5470
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Wummel (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.expanduser documentation wrt. empty $HOME
Initial Comment:
If $HOME is unset, an initial "~" should not be
expanded according to the documentation. But instead it
somehow is expanded, perhaps through the pwd module:
$ env -u HOME python -c "import os.path; print
os.path.expanduser('~/foo')"
/home/calvin/foo
The result should be "~/foo" instead of "/home/calvin/foo".
I suggest adjusting the documentation to state the also
a single "~" is looked up in the pwd module, not only
"~user".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193849&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1193890 ] calendar.weekheader not found in __all__
Bugs item #1193890, was opened at 2005-05-03 00: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=1193890&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: calendar.weekheader not found in __all__ Initial Comment: calendar.weekheader is documented and a public function form its beginning but not included in calendar.__all__. So >>> from calendar import *; weekheader triggers a NameError. Fix is trivial. Just add 'weekheader' to __all__. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193890&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1193966 ] Weakref types documentation bugs
Bugs item #1193966, was opened at 2005-05-02 14:31 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=1193966&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Weakref types documentation bugs Initial Comment: This page (section 3.3.3 of the library reference manual): http://www.python.org/doc/current/lib/weakref-extension.html#weakref-extension contains a description of what you need to do to make your extension types weakrefable. There are a few problems with this page. First, it really belongs in the C API and/or extending and embedding documentation, not in the library reference manual. Second, the page describes having to set Py_TPFLAGS_HAVE_WEAKREFS in tp_flags, but that's unnecessary because Py_TPFLAGS_HAVE_WEAKREFS is already in Py_TPFLAGS_DEFAULT. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193966&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1189330 ] LINKCC incorrect
Bugs item #1189330, was opened at 2005-04-25 11:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189330&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christoph Ludwig (cludwig) Assigned to: Nobody/Anonymous (nobody) Summary: LINKCC incorrect Initial Comment: I configured Python 2.4.1 as follows ../Python-2.4.1/configure \ --prefix=/home/cludwig/C++/gcc4.0/Python-2.4.1 \ --with-cxx=/opt/gcc/gcc-4.0.0/bin/g++ --enable-shared \ --enable-unicode --with-signal-module \ --with-universal-newlines --with-doc-strings on a i686-pc-linux-gnu system. make fails when linking the python binariy due to an undefined reference to `__gxx_personality_v0'. In fact, configure set CC= gcc -pthread CXX=/opt/gcc/gcc-4.0.0/bin/g++ -pthread LINKCC= $(PURIFY) $(CC) but the python executable needs to be linked with $(CXX). (Note the `--with-cxx' option in the configure command line.) I did not observe this problem with Python 2.4.0 / gcc 3.4.2. This seems to be a regression w.r.t. PR #569668 that was closed as fixed on 2002-12-03. I can submit config.log and the output of make on request. Regards Christoph -- >Comment By: Martin v. Löwis (loewis) Date: 2005-05-02 23:13 Message: Logged In: YES user_id=21627 Can you propose a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189330&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1188231 ] Rebuilding from source on RH9 fails (_tkinter.so missing)
Bugs item #1188231, was opened at 2005-04-22 20:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1188231&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Marty Heyman (mheyman) Assigned to: Nobody/Anonymous (nobody) Summary: Rebuilding from source on RH9 fails (_tkinter.so missing) Initial Comment: On a Red Hat 9 system, I downloaded the python2.4-2.4. 1-1pydotorg.src.rpm and, following the web page ran "rpm --rebuild . ..". It went a long for a good long while with no apparent errors and then said: --- RPM build errors: File not found by glob: /var/tmp/python2.4-2.4. 1-root/usr/lib/python2.4/lib-dynload/_tkinter.so* --- I looked in the directory and there is, in fact, no _tkinter.so file(s) there. -- Marty Heyman -- >Comment By: Martin v. Löwis (loewis) Date: 2005-05-02 23:16 Message: Logged In: YES user_id=21627 Ah, so it seems you are lacking the X11 header files. They should have been installed as a dependency on the Tk headers. So this is either a Redhat bug (for not including a dependency of the -dev packages) or a local misconfiguration of some kind (e.g. forcefully installing Tk headers without all prerequisites present). -- Comment By: Marty Heyman (mheyman) Date: 2005-04-22 20:42 Message: Logged In: YES user_id=421967 APOLOGIES: ADDITIONAL INFO FOLLOWS ---Snip from rebuild output follows In file included from /usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67: /usr/include/tk.h:83:29: X11/Xlib.h: No such file or directory In file included from /usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67: /usr/include/tk.h:581: parse error before "Bool" /usr/include/tk.h:583: parse error before "event" /usr/include/tk.h:584: parse error before "root" /usr/include/tk.h:585: parse error before "subwindow" /usr/include/tk.h:586: parse error before "time" /usr/include/tk.h:586: `time' redeclared as different kind of symbol /usr/include/time.h:184: previous declaration of `time' /usr/include/tk.h:591: parse error before "same_screen" --- snip ends many more "parse error lines occurred after this. I doubt they're interesting . A bit later, another group of failures begins --Snip starts In file included from /usr/include/tk.h:1361, from /usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67: /usr/include/tkDecls.h:37: parse error before '*' token /usr/include/tkDecls.h:39: parse error before "Tk_3DBorderGC" /usr/include/tkDecls.h:45: parse error before "Drawable" /usr/include/tkDecls.h:50: parse error before "Drawable" /usr/include/tkDecls.h:58: parse error before "XEvent" --Snip ends Again, there are many more similar messages following those and then: --Snip starts /usr/include/tkDecls.h:843: `GC' declared as function returning a function ... [parse errors] /usr/include/tkDecls.h:906: `Font' declared as function returning a function --Snip ends There are many such embedded in that group. Then the messages stop followed by a line that says: "running build_scripts" ... and things proceed as if all was OK for hundreds more lines of output before the failure copied into the original report. I captured the complete log and can upload it if needed on request. I'd need to trim it and it doesn't look all that interesting otherwise but then, what do I know :-) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1188231&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-1190689 ] logging module root logger name
Feature Requests item #1190689, was opened at 2005-04-26 20:19
Message generated for change (Comment added) made by cxdunn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190689&group_id=5470
Category: Python Library
Group: None
>Status: Open
>Resolution: None
Priority: 5
Submitted By: Christopher Dunn (cxdunn)
Assigned to: Vinay Sajip (vsajip)
Summary: logging module root logger name
Initial Comment:
I would like a trailing '.' to be ignored in names
passed to getLogger(), like a trainling '/' in a Unix path.
In module 'foo':
logfoo = getLogger('.foo.')
# logger '"" should be the parent of ".foo"
Elsewhere, controlled by the user of that module:
import foo
logdefault = getLogger('.')
hdlr = StreamHandler()
fmtr = Formatter("%(name)s:%(msg)s")
hdlr.setFormatter(fmtr)
logdefault.addHandler(hdlr)
Given this change, I would also like the name of the
default logger to be displayed as '.', or even "",
rather than 'root'. The current behavior is odd:
logfoo.info("Foo message")
displays
.foo:Foo message
buf
logdefault.info("Default message")
displays
root:Default message
I NEVER mentioned the word "root" anywhere! And I don't
think it's very descriptive.
I would rather see ANY of these:
:Default message
.:Default message
default:Default message
logging:Default message
These changes would make the system more intuitive.
-cxdunn
--
>Comment By: Christopher Dunn (cxdunn)
Date: 2005-05-02 18:23
Message:
Logged In: YES
user_id=1267419
There's a bug wrt renaming the root logger:
>>> import logging.config
>>> logging.root.name = "snafu"
>>> logging.config.fileConfig("test.cfg")
Traceback (most recent call last):
File "python2.3/logging/config.py", line 132, in fileConfig
llist.remove("root")
ValueError: list.remove(x): x not in list
This is no different in 2.4.
list.remove(root.name)
is an easy fix.
Also,
logging.getLogger() != logging.getLogger("root")
or any other name. I now access the root logger strictly via
logging.root
getRootLogger(), which is deprecated, should be preferred,
since the root logger's name is not actually in the hash-table.
We need to make a sharp distinction between the root logger
and the others. There is only one root; you cannot look it
up by name; and the "dot" hierarchy does not apply to the
root (for if it did, we would have to look specify children
as .child, a convention that you've already rejected).
-cxdunn
P.S.
I've posted some useful logging-related stuff at the
ActivePython Cookbook. Feel free to add any of that to the
module. Especially, the Unique filter could be added to
logging.filters
--
Comment By: Christopher Dunn (cxdunn)
Date: 2005-04-28 14:23
Message:
Logged In: YES
user_id=1267419
You're right! That works like a charm:
>>> import logging
>>> logging.getLogger().name = '.'
>>> logging.warning("I am root")
WARNING:.:I am root
>>> sub = logging.getLogger('.sub')
>>> sub.warning("I am a child")
WARNING:.sub:I am a child
Setting the root to "" also works:
>>> import logging
>>> logging.getLogger().name = ""
>>> logging.warning("I am root")
WARNING::I am root
>>> sub = logging.getLogger('sub')
>>> sub.warning("I am a child")
WARNING:sub:I am a child
I agree with your other points. The flexibility would add
little value. I brought this issue up b/c I was confused by
the docs. Clearly, But it is not so clear that "A" is a
child of "root".
* "A.B" is obviously a child of "A"
* ".A" is *clearly* a child of "."
* And "A" is presumably a child of "".
* But it is not so clear that "A" is a child of "root"
Since *everything* is a child of the root logger, that's
worth reiterating in the docs. And if there is truly only 1
root logger, then it should be possible to find it by name:
>>> import logging
>>> logging.getLogger().name ="."
>>> logging.warning("I am root")
WARNING:.:I am root
>>> unknown = logging.getLogger(".")
>>> unknown.warning("Who am I?")
WARNING:.:Who am I?
>>> unknown == logging.getLogger()
False
In fact:
>>> import logging
>>> logging.getLogger() == logging.getLogger() #just a test
True
>>> logging.getLogger() == logging.getLogger("root") #should
be same!
False
This is not an easy module to understand, but it's amazingly
powerful.
One last suggestion. You have logging.handlers. You could
also have logging.filters. For example:
class Opaque(Filter):
"""A simple way to prevent any messages from getting
through."""
def __init__(self, name=None): pass
def filter(self, rec): return False
class Unique(Filter):
"""Messages are allowed through just once.
The 'message' includes substitutions, but is not
formatted by the
handler. If it were, then practically all messages would
be unique!
"""
def __init__(self, name=""):
Filter.__init__(self, name)
self.reset()
def reset(self):
"""Act as i
[ python-Bugs-1194181 ] bz2.BZ2File doesn't handle modes correctly
Bugs item #1194181, was opened at 2005-05-02 22:39 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=1194181&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: bz2.BZ2File doesn't handle modes correctly Initial Comment: I've noticed that if I specify a file mode of 'U' to bz2.BZ2File, it will erase my file. That's bad. Specifying 'rU' works as expected. Basically, it assumes that you want a writable file unless it sees an 'r' in the mode, or no mode is given. Ugh. I've attached a patch that fixes this on CVS HEAD, it looks like it should apply cleanly to 2.4 as well. This is a backport candidate if I've ever seen one. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1194209 ] Error in section 4.2 of Python Tutorial
Bugs item #1194209, was opened at 2005-05-03 00:02 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=1194209&group_id=5470 Category: Documentation Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Andrina Kelly (andrina) Assigned to: Nobody/Anonymous (nobody) Summary: Error in section 4.2 of Python Tutorial Initial Comment: The example in section 4.2 of the on-line tutorial should read as follows: >>> # Measure some strings: ... a = ['cat', 'window', 'defenestrate'] >>> for x in a: ... print x, len(a) ... cat 3 window 6 defenestrate 12 currently the print line has len(x) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194209&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1194209 ] Error in section 4.2 of Python Tutorial
Bugs item #1194209, was opened at 2005-05-03 00:02 Message generated for change (Settings changed) made by andrina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194209&group_id=5470 Category: Documentation Group: Not a Bug Status: Open Resolution: None >Priority: 3 Submitted By: Andrina Kelly (andrina) Assigned to: Nobody/Anonymous (nobody) Summary: Error in section 4.2 of Python Tutorial Initial Comment: The example in section 4.2 of the on-line tutorial should read as follows: >>> # Measure some strings: ... a = ['cat', 'window', 'defenestrate'] >>> for x in a: ... print x, len(a) ... cat 3 window 6 defenestrate 12 currently the print line has len(x) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194209&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1194222 ] parsedate and Y2K
Bugs item #1194222, was opened at 2005-05-02 21: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=1194222&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Nottingham (mnot)
Assigned to: Nobody/Anonymous (nobody)
Summary: parsedate and Y2K
Initial Comment:
rfc822.parsedate and email.Utils.parsedate don't take Y2K into
account when parsing two-digit years, even though they're allowed by
RFC822. Even though that spec has since been superseded, there
are still systems generating dates in the old format, and RFC2616,
which bases its dates on RFC822, still allows two-digit years.
For example,
>>> email.Utils.parsedate("Sun, 6 Nov 94 08:49:37 GMT")
(94, 11, 6, 8, 49, 37, 0, 0, 0)
Here's a trivial patch to behave as outlined in the time module (I don't
test for time.accept2dyear because the input is outside the system's
control, and RFC-specified); it's against 2.3, but should be easy to
integrate into later versions.
125a126,130
> if yy < 100:
> if yy > 68:
> yy = yy + 1900
> else:
> yy = yy + 2000
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194222&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1194249 ] Minor bug in urllib docs
Bugs item #1194249, was opened at 2005-05-03 06:31
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=1194249&group_id=5470
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Georg Brandl (gbrandl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minor bug in urllib docs
Initial Comment:
The urllib docs contain an example which starts as follows:
# Use http://www.someproxy.com:3128 for http proxying
proxies = proxies={'http': 'http://www.someproxy.com:3128'}
filehandle = urllib.urlopen(some_url, proxies=proxies)
The double "proxies=" is most likely a mistake and
should be removed.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194249&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
