[ python-Bugs-1724099 ] Grammar error in Python Tutorial 2.5 section 8.3
Bugs item #1724099, was opened at 2007-05-23 11:29 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=1724099&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: sampson (sampson_uk) Assigned to: Nobody/Anonymous (nobody) Summary: Grammar error in Python Tutorial 2.5 section 8.3 Initial Comment: In section 8.3 of the Python Tutorial (2.5) sentance reads:- "One my also instantiate an exception first before raising it and add any attributes to it as desired." Suggest this is supposed to be "One may.." -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724099&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1724099 ] Grammar error in Python Tutorial 2.5 section 8.3
Bugs item #1724099, was opened at 2007-05-23 11:29 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724099&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.5 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: sampson (sampson_uk) Assigned to: Nobody/Anonymous (nobody) Summary: Grammar error in Python Tutorial 2.5 section 8.3 Initial Comment: In section 8.3 of the Python Tutorial (2.5) sentance reads:- "One my also instantiate an exception first before raising it and add any attributes to it as desired." Suggest this is supposed to be "One may.." -- >Comment By: Georg Brandl (gbrandl) Date: 2007-05-23 13:26 Message: Logged In: YES user_id=849994 Originator: NO Thanks, this is already fixed in SVN. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724099&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1724366 ] cPickle module doesn't work with universal line endings
Bugs item #1724366, was opened at 2007-05-23 18:42 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=1724366&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Geoffrey Bache (gjb1002) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle module doesn't work with universal line endings Initial Comment: On UNIX, I cannot read pickle files created on Windows using the cPickle module, even if I open the file with universal line endings. It works fine with the pickle module but is of course slower (and I have to read lots of them) I attach a test case that pickles and unpickles an smptlib.SMTP object, converting the file to DOS format in between. There is nothing special about SMTP, you can use any object at all in a different module. On my system (RHEL4 with Python 2.4.3) I get the following output: portmoller : pickletest.py cPickle unix2dos: converting file dump to DOS format ... Traceback (most recent call last): File "pickletest.py", line 14, in ? print load(readFile) ImportError: No module named smtplib portmoller : pickletest.py pickle unix2dos: converting file dump to DOS format ... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724366&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1722485 ] Option -OO doesn't remove docstrings
Bugs item #1722485, was opened at 2007-05-21 10:18 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722485&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Grzegorz Adam Hankiewicz (gradha) Assigned to: Nobody/Anonymous (nobody) Summary: Option -OO doesn't remove docstrings Initial Comment: I'm using Python 2.5.1 as said by the -V switch under Windows XP. I run one of my programs with -OO, which generates a good amount of .pyo files in the directory. According to -h the -OO parameter removes docstrings. However, when I open the .pyo files with vim I can see all the docstrings in plain text. Conclusion, docstrings are not being removed. I noticed this in 2.5, which prompted me to upgrade after this thread: http://sourceforge.net/mailarchive/forum.php?thread_name=464D5A57.2060809%40rastertech.es&forum_name=py2exe-users -- >Comment By: Thomas Heller (theller) Date: 2007-05-23 20:26 Message: Logged In: YES user_id=11105 Originator: NO I can confirm this bug (but have no time to work on a patch). This simple script prints 'the docs' when run with 'python2.5 -OO', but prints 'None' when run with Python2.4 (for example). IMO this should be fixed in the next maintainance release, so raising the priority. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722485&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1723338 ] Crash in ctypes callproc function with unicode string arg
Bugs item #1723338, was opened at 2007-05-22 12:43 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&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.5 Status: Open >Resolution: Works For Me Priority: 5 Private: No Submitted By: Colin Laplace (claplace) Assigned to: Thomas Heller (theller) Summary: Crash in ctypes callproc function with unicode string arg Initial Comment: I've recently came to a bug using ctypes. I was using ctypes to call a syscall and and passing it a string argument, which was in fact in unicode. This resulted in a python crash in the callproc function. You can easily reproduce the crash by launching the attached python file (or at this link: https://core.fluendo.com/elisa/trac/browser/branches/rewrite-1/elisa/extern/inotify.py ) tested with python 2.5 -- >Comment By: Thomas Heller (theller) Date: 2007-05-23 20:35 Message: Logged In: YES user_id=11105 Originator: NO Unfortunately your test script does not run for me (I don't have twisted installed on Linux). I fear this is not a bug. When the .argtypes attribute for a foreign function is not set, you can pass (among others) Python strings *and* Python unicode strings to the function. The foreign function will receive a 'char *' in the former case, and a 'wchar_t *' in the latter case - the unicode string will *not* be converted. If this is your problem, and the foreign function expects a 'char *', you have several choices: 1. You can convert the unicode string to an ascii string in the Python code yourself. 2. You can wrap the unicode string in a c_char_p instance, and ctypes will do the conversion for you. 3. You can set the correct .argtypes attribute on the function, and ctypes will do the conversion for you. If this is not your problem, please provide a self-contained test case. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-23 06:06 Message: Logged In: YES user_id=33168 Originator: NO Thomas, could you take a look? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1722348 ] urlparse.urlunparse forms file urls incorrectly
Bugs item #1722348, was opened at 2007-05-21 04:05
Message generated for change (Comment added) made by orsenthil
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722348&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Folz-Donahue (eigenlambda)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse.urlunparse forms file urls incorrectly
Initial Comment:
This is a conversation with the current Python interpreter.
>>> import urlparse
>>> urlparse.urlparse(urlparse.urlunparse(urlparse.urlparse("file:usr/bin/python")))
('file', 'usr', '/bin/python', '', '', '')
As you can see, the results are incorrect. The problem is in the urlunsplit
function:
def urlunsplit((scheme, netloc, url, query, fragment)):
if netloc or (scheme and scheme in uses_netloc and url[:2] != '//'):
if url and url[:1] != '/': url = '/' + url
url = '//' + (netloc or '') + url
if scheme:
url = scheme + ':' + url
if query:
url = url + '?' + query
if fragment:
url = url + '#' + fragment
return url
RFC 1808 (see http://www.ietf.org/rfc/rfc1808.txt ) specifies that a URL shall
have the following syntax:
:///;?#
The problem with the current version of urlunsplit is that it tests if there
are already two slashes before the 'url' section before outputting a URL. This
is incorrect because (1) RFC 1808 clearly specifies at least three slashes
between the end of the scheme portion and the beginning of the path portion and
(2) this method will strip the first few slashes from an arbitrary path
portion, which may require those slashes. Removing that url[:2] != '//' causes
urlunsplit to behave correctly when dealing with urls like
file:usr/bin/python .
--
Comment By: O.R.Senthil Kumaran (orsenthil)
Date: 2007-05-24 02:57
Message:
Logged In: YES
user_id=942711
Originator: NO
Hi Thomas,
Verified the Bug with Python 2.5 and verified the fix as well. Works
fine.
>>> urlparse(urlunparse(urlparse('file:home/ors')))
('file', '', '//home/ors', '', '', '')
>>> urlparse(urlunparse(urlparse('file:/home/ors')))
('file', '', '///home/ors', '', '', '')
>>> urlparse(urlunparse(urlparse('file://home/ors')))
('file', '', 'home/ors', '', '', '')
>>>
urlparse(urlunparse(urlparse(urlunparse(urlparse('file://home/ors')
('file', '', 'home/ors', '', '', '')
>>>
--
Comment By: Thomas Folz-Donahue (eigenlambda)
Date: 2007-05-21 04:42
Message:
Logged In: YES
user_id=1797315
Originator: YES
Some other issues with the urlparse module. Several constant lists
defined at the beginning of the module should be sets because they are only
used for testing if certain strings are in them. Also, urlunsplit() uses
the + operator way too much, creating strings that are immediately thrown
away. IMO, the alternative is actually more readable. Attaching a patch
(diff -u urlparse.py urlparse.py.new > urlparse.diff).
File Added: urlparse.diff
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722348&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
