[ python-Bugs-1690608 ] email.utils.formataddr() should be rfc2047 aware
Bugs item #1690608, was opened at 2007-03-29 09:27 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=1690608&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.utils.formataddr() should be rfc2047 aware Initial Comment: formataddr() should rfc2047 encode its name argument if necessary. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690608&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1685000 ] DoS asyncore vulnerability
Bugs item #1685000, was opened at 2007-03-21 10:15 Message generated for change (Comment added) made by billiejoex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685000&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: DoS asyncore vulnerability Initial Comment: DoS asyncore vulnerability asyncore, independently if used with select() or poll(), suffers a DoS-type vulnerability when a high number of simultaneous connections to handle simultaneously is reached. The number of maximum connections is system-dependent as well as the type of error raised. I attached two simple Proof of Concept scripts demonstrating such bug. If you want to try the behaviours listed below run the attached "asyncore_server.py" and "asyncore_client.py" scripts on your local workstation. On my Windows XP system (Python 2.5), independently if asyncore has been used to develop a server or a client, the error is raised by select() inside asyncore's "poll" function when 512 (socket_map's elements) simultaneous connections are reached. Here's the traceback I get: [...] connections: 510 connections: 511 connections: 512 Traceback (most recent call last): File "C:\scripts\asyncore_server.py", line 38, in asyncore.loop() File "C:\Python25\lib\asyncore.py", line 191, in loop poll_fun(timeout, map) File "C:\Python25\lib\asyncore.py", line 121, in poll r, w, e = select.select(r, w, e, timeout) ValueError: too many file descriptors in select() On my Linux Ubuntu 6.10 (kernel 2.6.17-10, Python 2.5) different type of errors are raised depending on the application (client or server). In an asyncore-based client the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'connect' method of 'dispatcher' class: [...] connections: 1018 connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_client.py", line 31, in File "asyncore.py", line 191, in loop File "asyncore.py", line 138, in poll File "asyncore.py", line 80, in write File "asyncore.py", line 76, in write File "asyncore.py", line 395, in handle_write_event File "asyncore_client.py", line 24, in handle_connect File "asyncore_client.py", line 9, in __init__ File "asyncore.py", line 257, in create_socket File "socket.py", line 156, in __init__ socket.error: (24, 'Too many open files') On an asyncore-based server the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'accept' method of 'dispatcher' class: [...] connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_server.py", line 38, in File "asyncore.py", line 191, in loop File "asyncore.py", line 132, in poll File "asyncore.py", line 72, in read File "asyncore.py", line 68, in read File "asyncore.py", line 384, in handle_read_event File "asyncore_server.py", line 16, in handle_accept File "asyncore.py", line 321, in accept File "socket.py", line 170, in accept socket.error: (24, 'Too many open files') -- >Comment By: billiejoex (billiejoex) Date: 2007-03-29 16:03 Message: Logged In: YES user_id=1357589 Originator: YES > The problem is that there's no portable way to know what the limit > on file descriptors is. Why don't put a try/except statement before creating a new socket's file-descriptor? I believe that such problem shouldn't be understimated. Actually asyncore is the only asynchronous module present in Python's stdlib. If asyncore suffers a DoS vulnerability it just means that writing a secure client/server application with Python without using a third-party library isn't possible. I wrote a modified version of asyncore that solves the problem with select (affecting Windows) but still can't find a way to solve the problem with socket's file-descriptors (affecting Unix). -- Comment By: Sam Rushing (rushing) Date: 2007-03-23 20:59 Message: Logged In: YES user_id=73736 Originator: NO The problem is that there's no portable way to know what the limit on file descriptors is. The 'classic' for select/poll is the FD_SETSIZE macro. But on some operating systems there is no such limit. [e.g., win32 does not use the 'lowest-free-int' model common to unix]. I believe that in Medusa there was a derived class or extension that counted the number of open sockets, and limited it, using something like a semaphore. -- You can respond by visiting: https://sou
[ python-Bugs-1682403 ] docutils clarification request for "rest"
Bugs item #1682403, was opened at 2007-03-16 19:58 Message generated for change (Comment added) made by jvickroy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682403&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 Private: No Submitted By: j vickroy (jvickroy) Assigned to: Nobody/Anonymous (nobody) Summary: docutils clarification request for "rest" Initial Comment: >From the definition of long_description: *'long string'* Multiple lines of plain text in reStructuredText format (see http://docutils.sf.net/). in: http://docs.python.org/dist/meta-data.html I incorrectly concluded that the the bdist_wininst installer would provide visual markup for long_description specified in restructured text. According to Thomas Heller, that is not the case. I wish to suggest adding this clarification to the distutils documentation perhaps in one or both of the following documents: http://docs.python.org/dist/postinstallation-script.html http://docs.python.org/dist/meta-data.html Thanks, -- jv -- >Comment By: j vickroy (jvickroy) Date: 2007-03-29 14:26 Message: Logged In: YES user_id=17213 Originator: YES I expected bold font when using "**" markers, list bullets when using "*" and "-" markers, etc. in the long_description text definition. Unfortunately, all of these markers are simply passed through unprocessed in the long description text that appears in the opening window when running the generated binary installer. Does this help clarify the issue? -- Comment By: Collin Winter (collinwinter) Date: 2007-03-28 23:46 Message: Logged In: YES user_id=1344176 Originator: NO I'm not quite sure what the problem is. What kind of "visual markup" did you expect? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682403&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1493676 ] time.strftime() %z error
Bugs item #1493676, was opened at 2006-05-23 16:58
Message generated for change (Comment added) made by csharkey
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error
Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().
However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:
>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +'
This same problem happens for other timezones (the
offset is always + when localtime() is explicitly
given).
This problem is present in both these versions:
Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2
Python 2.3.5 (#2, Sep 4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
--
>Comment By: Cillian Sharkey (csharkey)
Date: 2007-03-29 16:44
Message:
Logged In: YES
user_id=1527351
Originator: YES
Hi all, glad to see this bug is being addressed!
Paul - thanks for your work, I hope your patching efforts make it into the
tree.
--
Comment By: Paul Boddie (pboddie)
Date: 2007-02-23 23:26
Message:
Logged In: YES
user_id=226443
Originator: NO
See patch #1667546 for a somewhat tested implementation of the changes
mentioned below.
--
Comment By: Paul Boddie (pboddie)
Date: 2007-02-23 23:13
Message:
Logged In: YES
user_id=226443
Originator: NO
It's probably too late to change details of the time tuple (far too much
code now depends on it), but I have patches against 2.4.4 which provide an
additional function called localtime_tz, which itself returns a localtime
tuple containing the additional "GMT offset" field. With some modifications
to various internal functions, the "struct tm" data can be populated and
strftime can then produce the desired result.
With regard to datetime, it does support time zones, but there's a
relatively large of work required to get "aware" datetime objects. I noted
this situation in the referenced newsgroup message on this topic.
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 18:33
Message:
Logged In: YES
user_id=1209659
Originator: NO
Thanks, I'll let this go. (datetime is even worse - it does not handle any
timezone data, and requires users to create their own timezone info).
So right now Python has no support for the functions that are readily
available to GNU C-lib users of time, that's that, and I won't argue about
it, will just assume Python cannot produce RFC 822 conformant dates with
standard libraries. (Perl, PHP, all work fine (but they are not Python)).
(C-lib strftime has no problems printing %z with the time-tuple - with
just dst info - because it is supposed to be the local time zone as set on
the computer. No data needed in the tuple.
>From the man page:
%z The time-zone as hour offset from GMT. Required to
emit
RFC 822-conformant dates (using "%a, %d %b %Y %H:%M:%S
%z").
(GNU)
)
--
Comment By: Brett Cannon (bcannon)
Date: 2007-02-23 17:23
Message:
Logged In: YES
user_id=357491
Originator: NO
OK, but that is an issue of how much information is stored in the time
tuple. There is no UTC offset or timezone information stored in the tuple
beyond whether DST is on or not. That is just an inherit shortcoming of
the time tuple. You can't fix that without adding a new field to the time
tuple itself.
I am personally not about to do that, but if someone wants to write a
patch it might be considered. But you will also need to discuss why this
should be done over just moving to datetime (and possibly fixing it there
if there are problems there as well).
--
Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 15:38
Message:
Logged In: YES
user_id=1209659
Originator: NO
To continue my previous comment, here's the snippet of a posting from
comp.lang.python discussion, posted by "Paul Boddie":
As far as I
[ python-Bugs-1290505 ] strptime(): can't switch locales more than once
Bugs item #1290505, was opened at 2005-09-14 00:50
Message generated for change (Comment added) made by kovan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Adam Monsen (meonkeys)
Assigned to: Brett Cannon (bcannon)
Summary: strptime(): can't switch locales more than once
Initial Comment:
After calling strptime() once, it appears that
subsequent efforts to modify the locale settings (so
dates strings in different locales can be parsed) throw
a ValueError. I'm pasting everything here since spacing
is irrelevant:
import locale, time
print locale.getdefaultlocale()# ('en_US', 'utf')
print locale.getlocale(locale.LC_TIME) # (None, None)
# save old locale
old_loc = locale.getlocale(locale.LC_TIME)
locale.setlocale(locale.LC_TIME, 'nl_NL')
print locale.getlocale(locale.LC_TIME) # ('nl_NL',
'ISO8859-1')
# parse local date
date = '10 augustus 2005 om 17:26'
format = '%d %B %Y om %H:%M'
dateTuple = time.strptime(date, format)
# switch back to previous locale
locale.setlocale(locale.LC_TIME, old_loc)
print locale.getlocale(locale.LC_TIME) # (None, None)
date = '10 August 2005 at 17:26'
format = '%d %B %Y at %H:%M'
dateTuple = time.strptime(date, format)
The output I get from this script is:
('en_US', 'utf')
(None, None)
('nl_NL', 'ISO8859-1')
(None, None)
Traceback (most recent call last):
File "switching.py", line 17, in ?
dateTuple = time.strptime(date, format)
File "/usr/lib/python2.4/_strptime.py", line 292, in
strptime
raise ValueError("time data did not match format:
data=%s fmt=%s" %
ValueError: time data did not match format: data=10
August 2005 at 17:26 fmt=%d %B %Y at %H:%M
One workaround I found is by manually busting the
regular expression cache in _strptime:
import _strptime
_strptime._cache_lock.acquire()
_strptime._TimeRE_cache = _strptime.TimeRE()
_strptime._regex_cache = {}
_strptime._cache_lock.release()
If I do all that, I can change the LC_TIME part of the
locale as many times as I choose.
If this isn't a bug, this should at least be in the
documentation for the locale module and/or strptime().
--
Comment By: Javier Sanz (kovan)
Date: 2007-03-29 18:53
Message:
Logged In: YES
user_id=1426755
Originator: NO
I've been looking at the test case, and I noticed that isn't actually
checking anything, because locale.getlocale(locale.LC_TIME) is returning
(None,None), which is ok and just means that the default locale (which is
the C locale, not the system locale) is being used.
After removing that 'if' I also changed de_DE by es_ES to fit my system,
and strptime('10', '%d') by strptime('Fri', '%a') and strptime('vie','%a');
because '10' is '10' in all -occidental- languages, and the test would not
fail when the wrong locale is being used.
Once I made these changes to the test case, it successfully failed when
using the non-patched _strptime.py, AND ran ok when using the patched
version.
This is the test case I ended up using:
def test_TimeRE_recreation(self):
# The TimeRE instance should be recreated upon changing the
locale.
locale_info = locale.getlocale(locale.LC_TIME)
locale.setlocale(locale.LC_TIME, ('en_US', 'UTF8'))
try:
_strptime.strptime('Fri', '%a')
first_time_re_id = id(_strptime._TimeRE_cache)
locale.setlocale(locale.LC_TIME, ('es_ES', 'UTF8'))
_strptime.strptime('vie', '%a')
second_time_re_id = id(_strptime._TimeRE_cache)
self.failIfEqual(first_time_re_id, second_time_re_id)
finally:
locale.setlocale(locale.LC_TIME, locale_info)
--
Comment By: Brett Cannon (bcannon)
Date: 2007-03-29 04:07
Message:
Logged In: YES
user_id=357491
Originator: NO
I have uploaded a patch for test_strptime that adds a test to make sure
that the TimeRE instance is recreated if the locale changes (went with
en_US and de_DE, but could easily be other locales if there are other ones
that are more common). Let me know if the test runs fine and works. Even
better is if it fails without the fix.
File Added: strptime_timere_test.diff
--
Comment By: Javier Sanz (kovan)
Date: 2007-03-29 01:44
Message:
Logged In: YES
user_id=1426755
Originator: NO
I'll be glad to help in whatever I can.
--
Comment By: Brett Cannon (bcannon)
Date: 2007-03-29 01:40
Message:
Logged In: YES
user_id=357491
Originator: NO
The power of procrastination in the m
[ python-Bugs-1615275 ] tempile.TemporaryFile differences between linux and windows
Bugs item #1615275, was opened at 2006-12-13 16:20 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1615275&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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: hirzel (hirzel) Assigned to: Nobody/Anonymous (nobody) Summary: tempile.TemporaryFile differences between linux and windows Initial Comment: This bug came up when trying to write a numpy array to a tempfile.TemporaryFile() using the numpy 'tofile' method on windows using python 2.4. with a numpy array 'a', and a TemporaryFile 'f', on windows: >>> a.tofile(f) throws an IOError, where on Linux it does not. On windows, you must use a.tofile(f.file) The cause of this difference is that in windows, tempfile.TemporaryFile() returns that has a 'file' attribute of , whereas in linux tempfile.TemporaryFile() returns and there is no 'file' attribute. Ideally, the windows version would align with linux, and the module documentation and TemporaryFile() would return a . If this is not possible, it seems like the linux version and docs should be changed to match the windows version to align cross-platform behavior. At least, that seems to be the shared opinion of this thread from the mailing list: numpy-discussion. http://www.mail-archive.com/[email protected]/msg00271.html To my knowledge, while platform differences in tempfile have been reported in the past, this one has not. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-03-29 14:36 Message: Logged In: YES user_id=984087 Originator: NO After looking at tempfile.py, the reason for the difference in behaviour is clear. On windows, "TemporaryFile" is an alias for "NamedTemporaryFile". NamedTemporaryFile() returns a wrapper instance with file-like interface but which is not actually a file. This is not a problem when file operations like "write" and "close" are used directly. But array.tofile() explicitly checks for file type object and hence fails with NamedTemporaryFile(). Same is the reason for numpy failure as reported by OP (I haven't explicitly analyzed numpy failure but gleaned this info from the discussion thread in the initial post). Even though the reason is clear, I think the end result is a bit unsatisfactory. array.tofile() (and numpy's tofile()) need to pass different parameters depending on the platform. One possible solution is for "TemporaryFile" to return a wrapper as well. Then, tofile() can be called with TemporaryFile().file on all platforms. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-03-28 10:43 Message: Logged In: YES user_id=984087 Originator: NO I used the following code to reproduce the problem on windows XP. -- import array import tempfile testarray = array.array('B') testarray.fromstring("\x00\x00\x00") f = tempfile.TemporaryFile() testarray.tofile(f) --- This works fine on linux but on windows, it gives the following error: - Traceback (most recent call last): File "c:\rags\tofile.py", line 7, in testarray.tofile(f) TypeError: arg must be open file - Changing "f" to "f.file" seems to work, though, as explained in the initial post. So this may be the same problem as OP reported even though I am getting TypeError and he mentioned IOError. I tested with 2.4 and 2.5 as I don't know how to set up python development environment on windows (yet). I will see if I can set that up first before working on the "fix". Raghu. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1615275&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1690840 ] xmlrpclib methods submit call on __str__, __repr__
Bugs item #1690840, was opened at 2007-03-29 19:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690840&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: Greg Hazel (ghazel)
Assigned to: Nobody/Anonymous (nobody)
Summary: xmlrpclib methods submit call on __str__, __repr__
Initial Comment:
Notice how trying to print a method causes it to submit the call:
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from xmlrpclib import ServerProxy
>>> s = ServerProxy("http://google.com";)
>>> print s.somecall
Traceback (most recent call last):
File "", line 1, in
File "c:\python25\lib\xmlrpclib.py", line 1147, in __call__
return self.__send(self.__name, args)
File "c:\python25\lib\xmlrpclib.py", line 1437, in __request
verbose=self.__verbose
File "c:\python25\lib\xmlrpclib.py", line 1191, in request
headers
xmlrpclib.ProtocolError: >> f = s.somecall
>>> locals()
{'f': Traceback (most recent call last):
File "", line 1, in
File "c:\python25\lib\xmlrpclib.py", line 1147, in __call__
return self.__send(self.__name, args)
File "c:\python25\lib\xmlrpclib.py", line 1437, in __request
verbose=self.__verbose
File "c:\python25\lib\xmlrpclib.py", line 1191, in request
headers
xmlrpclib.ProtocolError:
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690840&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1290505 ] strptime(): can't switch locales more than once
Bugs item #1290505, was opened at 2005-09-13 15:50
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Adam Monsen (meonkeys)
Assigned to: Brett Cannon (bcannon)
Summary: strptime(): can't switch locales more than once
Initial Comment:
After calling strptime() once, it appears that
subsequent efforts to modify the locale settings (so
dates strings in different locales can be parsed) throw
a ValueError. I'm pasting everything here since spacing
is irrelevant:
import locale, time
print locale.getdefaultlocale()# ('en_US', 'utf')
print locale.getlocale(locale.LC_TIME) # (None, None)
# save old locale
old_loc = locale.getlocale(locale.LC_TIME)
locale.setlocale(locale.LC_TIME, 'nl_NL')
print locale.getlocale(locale.LC_TIME) # ('nl_NL',
'ISO8859-1')
# parse local date
date = '10 augustus 2005 om 17:26'
format = '%d %B %Y om %H:%M'
dateTuple = time.strptime(date, format)
# switch back to previous locale
locale.setlocale(locale.LC_TIME, old_loc)
print locale.getlocale(locale.LC_TIME) # (None, None)
date = '10 August 2005 at 17:26'
format = '%d %B %Y at %H:%M'
dateTuple = time.strptime(date, format)
The output I get from this script is:
('en_US', 'utf')
(None, None)
('nl_NL', 'ISO8859-1')
(None, None)
Traceback (most recent call last):
File "switching.py", line 17, in ?
dateTuple = time.strptime(date, format)
File "/usr/lib/python2.4/_strptime.py", line 292, in
strptime
raise ValueError("time data did not match format:
data=%s fmt=%s" %
ValueError: time data did not match format: data=10
August 2005 at 17:26 fmt=%d %B %Y at %H:%M
One workaround I found is by manually busting the
regular expression cache in _strptime:
import _strptime
_strptime._cache_lock.acquire()
_strptime._TimeRE_cache = _strptime.TimeRE()
_strptime._regex_cache = {}
_strptime._cache_lock.release()
If I do all that, I can change the LC_TIME part of the
locale as many times as I choose.
If this isn't a bug, this should at least be in the
documentation for the locale module and/or strptime().
--
>Comment By: Brett Cannon (bcannon)
Date: 2007-03-29 13:03
Message:
Logged In: YES
user_id=357491
Originator: NO
The test was checking that the TimeRE instance is recreated when the
locale changes. You do have a valid point about the 'if' check; should
have put the setlocale call in an try/except block and just returned if an
exception was raised.
As for the %d usage of strptime, that is just to force a call into
strptime and thus trigger the new instance of TimeRE. That is why the test
checks the id of the objects; don't really care about strptime directly
failing. Did the test not fail properly even when you removed the 'if' but
left everything else alone?
--
Comment By: Javier Sanz (kovan)
Date: 2007-03-29 09:53
Message:
Logged In: YES
user_id=1426755
Originator: NO
I've been looking at the test case, and I noticed that isn't actually
checking anything, because locale.getlocale(locale.LC_TIME) is returning
(None,None), which is ok and just means that the default locale (which is
the C locale, not the system locale) is being used.
After removing that 'if' I also changed de_DE by es_ES to fit my system,
and strptime('10', '%d') by strptime('Fri', '%a') and strptime('vie','%a');
because '10' is '10' in all -occidental- languages, and the test would not
fail when the wrong locale is being used.
Once I made these changes to the test case, it successfully failed when
using the non-patched _strptime.py, AND ran ok when using the patched
version.
This is the test case I ended up using:
def test_TimeRE_recreation(self):
# The TimeRE instance should be recreated upon changing the
locale.
locale_info = locale.getlocale(locale.LC_TIME)
locale.setlocale(locale.LC_TIME, ('en_US', 'UTF8'))
try:
_strptime.strptime('Fri', '%a')
first_time_re_id = id(_strptime._TimeRE_cache)
locale.setlocale(locale.LC_TIME, ('es_ES', 'UTF8'))
_strptime.strptime('vie', '%a')
second_time_re_id = id(_strptime._TimeRE_cache)
self.failIfEqual(first_time_re_id, second_time_re_id)
finally:
locale.setlocale(locale.LC_TIME, locale_info)
--
Comment By: Brett Cannon (bcannon)
Date: 2007-03-28 19:07
Message:
Logged In: YES
user_id=357491
Originator: NO
I have uploaded a patch for test_strptime that adds a test to make sure
[ python-Bugs-1689617 ] Intel icc build fails with optimizations -O2
Bugs item #1689617, was opened at 2007-03-28 04:26 Message generated for change (Comment added) made by mforbes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689617&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: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Forbes (mforbes) Assigned to: Nobody/Anonymous (nobody) Summary: Intel icc build fails with optimizations -O2 Initial Comment: When building python 2.5 with the free Intel compilers for non-commercial use (icc), the build works without optimizations, but fails when optimizations -O2 and -O3 are used. The compilation proceedes without errors (though there are lot's of warnings and remarks) and makes a python executable, but when the python setup starts, the intepreter cannot import certain packages and cannot add two strings. case $MAKEFLAGS in \ *-s*) CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 -Ob2 -w1' ./python -E ./setup.py -q build;; \ *) CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 -Ob2 -w1' ./python -E ./setup.py build;; \ esac 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in import sys, os, imp, re, optparse File "/int/apps/mmf/src/Python-2.5_intel/Lib/optparse.py", line 71, in import textwrap File "/int/apps/mmf/src/Python-2.5_intel/Lib/textwrap.py", line 10, in import string, re File "/int/apps/mmf/src/Python-2.5_intel/Lib/string.py", line 26, in letters = lowercase + uppercase SystemError: error return without exception set make: *** [sharedmods] Error 1 For example: $ ./python 'import site' failed; use -v for traceback Python 2.5 (r25:51908, Mar 27 2007, 20:10:22) [GCC Intel(R) C++ gcc 3.4 mode] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = "123" >>> a + "12" Traceback (most recent call last): File "", line 1, in SystemError: error return without exception set >>> Note that both the import of the site file fails and the addition fails. Python was configured with the following options: ./configure --with-gcc=icc\ --with-cxx-main=icc\ --prefix=/int/apps/mmf/apps/Python-2.5_intel/\ OPT="-g -O2 -Ob2 -w1" When compiled with fewer optimiztions, everything seems to work. ./configure --with-gcc=icc\ --with-cxx-main=icc\ --prefix=/int/apps/mmf/apps/Python-2.5_intel/\ OPT="-g -O1 -Ob2 -w1" -- >Comment By: Michael Forbes (mforbes) Date: 2007-03-29 22:06 Message: Logged In: YES user_id=253921 Originator: YES I have spoken with some people who have had similar issues with the intel compilers in other applications, so it looks like it might be a compiler bug. I will look into this. Can anyone confirm this behaviour? (I only have access to one linux box). -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-28 11:32 Message: Logged In: YES user_id=21627 Originator: NO Can you debug this further to determine a specific problem? It could be a compiler bug also, for all I can tell. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689617&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-705836 ] struct.pack of floats in non-native endian order
Bugs item #705836, was opened at 2003-03-18 15:17
Message generated for change (Comment added) made by collinwinter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&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: None
>Status: Open
Resolution: Fixed
Priority: 7
Private: No
Submitted By: Richard Hill (richardh2003)
Assigned to: Tim Peters (tim_one)
Summary: struct.pack of floats in non-native endian order
Initial Comment:
Python version 2.1 (2.2.1 behaves the same).
Windows 2000 and RH Linux 8.0
This was run on an Intel platform.
>>> v = 7.0 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1
+ .1
>>> v
7.9964
>>> struct.pack( "f", v )
'\x00\x00\x00A'
>>> struct.pack( ">f", v )
'@\x80\x00\x00'
These two should be the same byte pattern (only
reversed)!
>>> struct.unpack( ">f", '@\x80\x00\x00' )
(4.0,)
!
--
>Comment By: Collin Winter (collinwinter)
Date: 2007-03-29 18:38
Message:
Logged In: YES
user_id=1344176
Originator: NO
Reopening. The test case committed in r31892 is broken, specifically the
part that checks for an OverflowError towards the end: the TestFailed
exception is only instanced, never raised. Actually raising the TestFailed
instance causes the test to fail.
--
Comment By: Tim Peters (tim_one)
Date: 2003-03-20 13:48
Message:
Logged In: YES
user_id=31435
Fixed. In the 2.2 branch:
Lib/test/test_struct.py; new revision: 1.14.12.1
Misc/NEWS; new revision: 1.337.2.4.2.68
Modules/cPickle.c; new revision: 2.73.2.1.2.4
Modules/structmodule.c; new revision: 2.51.8.2
For 2.3:
Lib/test/test_struct.py; new revision: 1.17
Misc/NEWS; new revision: 1.700
Modules/cPickle.c; new revision: 2.141
Modules/structmodule.c; new revision: 2.58
--
Comment By: Richard Hill (richardh2003)
Date: 2003-03-20 07:33
Message:
Logged In: YES
user_id=737060
Thanks for getting back to me.
Your comment regarding IEEE formats is very interesting, I
didn't know about this behaviour.
--
Comment By: Tim Peters (tim_one)
Date: 2003-03-20 00:25
Message:
Logged In: YES
user_id=31435
Boosted priority because this is an especially bad kind of
bug: mysterious, subtle, and very rare ("most" in-range
floats pack under "f" without
problems; a problem
requires that a carry out of the 25th most-significant-bit
propagate thru a solid string of 24 1 bits).
For 2.2 I expect to check in a quick hack. In 2.3 this code
needs refactoring (structmodule and cPickle shouldn't have
duplicated this delicate code)
--
Comment By: Tim Peters (tim_one)
Date: 2003-03-19 14:01
Message:
Logged In: YES
user_id=31435
Yuck. It's a bug in not accounting for that rounding can
spill over the original bit width. structmodule's pack_float()
and pack_double() both have this flaw, although the one in
pack_double() is much subtler. A similar cut-and-paste
bug is in cPicke's save_float(). I'll fix all this.
Note: while "f"'s, there's no defined relationship between either of
those and plain "f". "f" is platform-native in all
respects. "f" force an IEEE-like encoding, even on non-IEEE
platforms.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1530559 ] struct.pack raises TypeError where it used to convert
Bugs item #1530559, was opened at 2006-07-28 14:07
Message generated for change (Comment added) made by collinwinter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&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: 9
Private: No
Submitted By: Joe Wreschnig (piman)
Assigned to: Bob Ippolito (etrepum)
Summary: struct.pack raises TypeError where it used to convert
Initial Comment:
[EMAIL PROTECTED]:~$ python2.4 -c "import struct;
struct.pack('>H', 1.0)"
[EMAIL PROTECTED]:~$ python2.5 -c "import struct;
struct.pack('>H', 1.0)"
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/struct.py", line 63, in pack
return o.pack(*args)
TypeError: unsupported operand type(s) for &: 'float'
and 'long'
This might have appeared as part of the struct
optimizations; if struct isn't going to convert anymore
for performance reasons, I think this should be
mentioned in the release notes. Though personally I
would prefer struct go back to converting its arguments.
--
>Comment By: Collin Winter (collinwinter)
Date: 2007-03-29 18:48
Message:
Logged In: YES
user_id=1344176
Originator: NO
Reopening. The test case added in r51119 (specifically, test_1530559() and
its infrastructure) doesn't work. The check_float_coerce() function is
overwritten by a later assignment, meaning that test_1530559() calls the
wrong function. Actually making it call the right check_float_coerce()
function results in a NameError ("global name 'func' is not defined").
The reason the test currently passes is because check_float_coerce() is
effectively an alias for deprecated_err(). test_1530559() passes
deprecated_err() a string as its first argument; when deprecated_err()
tries to call the string, a TypeError results. deprecated_err() traps the
TypeError and so everything appears from the outside to have gone
smoothly.
If the test is tweaked so that struct.pack() is actually invoked with the
proper arguments, it fails to raise the expected error on float coercion.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-11 00:27
Message:
Logged In: YES
user_id=33168
This patch (or some variant) was checked in as 51119
--
Comment By: Bob Ippolito (etrepum)
Date: 2006-08-02 22:10
Message:
Logged In: YES
user_id=139309
I've attached a patch which should resolve this issue.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-28 23:21
Message:
Logged In: YES
user_id=33168
I'd like to see a deprecation warning so old code continues
to work. struct is way to loose and needs to be tightened
up, but that might not fully happen until py3k.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 15:44
Message:
Logged In: YES
user_id=849994
I think that's a question for python-dev.
--
Comment By: Bob Ippolito (etrepum)
Date: 2006-07-28 15:31
Message:
Logged In: YES
user_id=139309
That wasn't really intentional, but the old behavior looks a bit suspect:
$ python2.4 -c "import struct; print repr(struct.pack('>H', 1.6))"
'\x00\x01'
We could change it to check for floats and do a DeprecationWarning?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 14:51
Message:
Logged In: YES
user_id=849994
Bob?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1690840 ] xmlrpclib methods submit call on __str__, __repr__
Bugs item #1690840, was opened at 2007-03-29 15:14
Message generated for change (Comment added) made by collinwinter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690840&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: Greg Hazel (ghazel)
Assigned to: Nobody/Anonymous (nobody)
Summary: xmlrpclib methods submit call on __str__, __repr__
Initial Comment:
Notice how trying to print a method causes it to submit the call:
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from xmlrpclib import ServerProxy
>>> s = ServerProxy("http://google.com";)
>>> print s.somecall
Traceback (most recent call last):
File "", line 1, in
File "c:\python25\lib\xmlrpclib.py", line 1147, in __call__
return self.__send(self.__name, args)
File "c:\python25\lib\xmlrpclib.py", line 1437, in __request
verbose=self.__verbose
File "c:\python25\lib\xmlrpclib.py", line 1191, in request
headers
xmlrpclib.ProtocolError: >> f = s.somecall
>>> locals()
{'f': Traceback (most recent call last):
File "", line 1, in
File "c:\python25\lib\xmlrpclib.py", line 1147, in __call__
return self.__send(self.__name, args)
File "c:\python25\lib\xmlrpclib.py", line 1437, in __request
verbose=self.__verbose
File "c:\python25\lib\xmlrpclib.py", line 1191, in request
headers
xmlrpclib.ProtocolError:
--
>Comment By: Collin Winter (collinwinter)
Date: 2007-03-29 22:59
Message:
Logged In: YES
user_id=1344176
Originator: NO
What would you rather seem them print?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690840&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1682403 ] docutils clarification request for "rest"
Bugs item #1682403, was opened at 2007-03-16 15:58 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682403&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: 3 Private: No Submitted By: j vickroy (jvickroy) >Assigned to: Martin v. Löwis (loewis) Summary: docutils clarification request for "rest" Initial Comment: From the definition of long_description: *'long string'* Multiple lines of plain text in reStructuredText format (see http://docutils.sf.net/). in: http://docs.python.org/dist/meta-data.html I incorrectly concluded that the the bdist_wininst installer would provide visual markup for long_description specified in restructured text. According to Thomas Heller, that is not the case. I wish to suggest adding this clarification to the distutils documentation perhaps in one or both of the following documents: http://docs.python.org/dist/postinstallation-script.html http://docs.python.org/dist/meta-data.html Thanks, -- jv -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-29 23:03 Message: Logged In: YES user_id=1344176 Originator: NO Martin, you handle a lot of the Windows-related code, right? Thoughts on this? -- Comment By: j vickroy (jvickroy) Date: 2007-03-29 10:26 Message: Logged In: YES user_id=17213 Originator: YES I expected bold font when using "**" markers, list bullets when using "*" and "-" markers, etc. in the long_description text definition. Unfortunately, all of these markers are simply passed through unprocessed in the long description text that appears in the opening window when running the generated binary installer. Does this help clarify the issue? -- Comment By: Collin Winter (collinwinter) Date: 2007-03-28 19:46 Message: Logged In: YES user_id=1344176 Originator: NO I'm not quite sure what the problem is. What kind of "visual markup" did you expect? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682403&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1688274 ] Python/C PyClass_* are not documented
Bugs item #1688274, was opened at 2007-03-26 07:24 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&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 Private: No Submitted By: Tommi Vainikainen (tvainika) Assigned to: Nobody/Anonymous (nobody) Summary: Python/C PyClass_* are not documented Initial Comment: Python/C API Reference Manual chapter 7.5 Other Objects does not contain subchapter for Class objects, but only Instance objects and many other are documented there. >From header I can find that at least PyClass_Check and PyClass_New exist, I >just don't know what those do until I take time to read source code... :( -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-29 23:24 Message: Logged In: YES user_id=1344176 Originator: NO Take a look at the attached patch and see if that says what you want. File Added: concrete.tex.diff -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1686475 ] os.stat() WindowsError 13 when file in use
Bugs item #1686475, was opened at 2007-03-23 03:31
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: d roberts (dcroberts)
Assigned to: Martin v. Löwis (loewis)
Summary: os.stat() WindowsError 13 when file in use
Initial Comment:
Using 2.5 Sept 19, 2006 on Windows XP, 32-bit.
os.stat() on an "in use" file (i.e., open by another process) erroneously
returns WindowsError [Error 13]. The file stats should be available on an open
file, even if you cannot read/write the file itself.
Python 2.4 correctly returns the stats on the file.
CORRECT in 2.4:
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32
>>> import os
>>> os.stat('c:\\hiberfil.sys')
(33206, 0L, 2, 1, 0, 0, 804311040L, 1173962381, 1173962381, 1069302780)
-
ERROR in 2.5:
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on
win32
>>> import os
>>> os.stat("c:\\hiberfil.sys")
Traceback (most recent call last):
File "", line 1, in
WindowsError: [Error 13] The process cannot access the file because it is being
used by another process: 'c:\\hiberfil.sys'
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-03-30 08:29
Message:
Logged In: YES
user_id=21627
Originator: NO
Attached is a patch that makes it fall back to FindFirstFile if
GetFileAttributesEx fail with ERROR_SHARING_VIOLATION.
File Added: stat.diff
--
Comment By: d roberts (dcroberts)
Date: 2007-03-23 18:49
Message:
Logged In: YES
user_id=1750755
Originator: YES
Taking your hint, I just looked at the code in 42230 which uses the Win32
GetFileAttributesEx() function. This function does indeed return an error
for an in-use file. Not sure if this is a "feature" or "bug" in the
underlying Windows function. I did try FindFirstFile(), which is able to
return info on an in-use file. Not sure if this is a reasonable alternative
to GFAE(), but wanted to make folks aware of the possibility. It's probably
slower, since it can handle wild-cards, and returns a handle for subsequent
calls to FindNextFile(). The handle must be closed with FindClose(). I'm
not sure what underlying mechanism FindFirstFile() uses, but I'm assuming
it accesses the "directory" to get its information, rather than trying to
access the file itself. FWIW.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-03-23 11:24
Message:
Logged In: YES
user_id=21627
Originator: NO
It certainly is; Python is likely opening the file in the wrong mode now.
I'll investigate, although contributions would be welcome.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-03-23 11:15
Message:
Logged In: YES
user_id=849994
Originator: NO
May this be related to rev. 42230 - "Drop C library for stat/fstat on
Windows." ?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&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-1465406 ] Allowing the definition of constants
Feature Requests item #1465406, was opened at 2006-04-05 19:30 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&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: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Chris Wilson (ciw42) Assigned to: Nobody/Anonymous (nobody) Summary: Allowing the definition of constants Initial Comment: One of the current optimizations due in v2.5 includes constant folding of expressions, which as it stands serves as a way of somply getting rid of a redundant arithmetic operations and the like. In practice, it's rare a developer would leave an expression such as "2+3" sat in his/her code, but by allowing the declaration of constants within a script, it could make this new feature *much* more useful. As an example, in a recent script I had the following at the top, outside the main loop: SCREEN_WIDTH=640 SCREEN_HEIGHT=480 SCREEN_RATIO=SCREEN_WIDTH/SCREEN_HEIGHT As SCREEN_RATIO is used a number of times during my main loop, it makes sense to pre-calculate it to avoid the extra processing, but if the compiler were aware that SCREEN_WIDTH and SCREEN_HEIGHT were constants, it could optimise out the calculation and I could include the calculation in-place. I frequently make use of "constants" to make my code more readable, and wonder whether there is any performance penalty or lack of optimisation going on due to them in fact being regular variables? -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 03:11 Message: Logged In: YES user_id=1344176 Originator: NO The PEP Raymond mentioned hasn't been written (to Google's knowledge), and I can't see much support for it even if it were to be written. The performance benefits from a "const" keyword would in my view be minimal and not worth adding the necessary complication to the compiler. Closing. -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-05-09 00:51 Message: Logged In: YES user_id=80475 Introducing a new keyword, "const", requires a PEP. Such a PEP should be backed-up by timings that demonstrate performance improvements impressive enough to warrant a change. In my experience, replacing global lookups with constants almost never produces much a speed-up in real code. If you write a PEP, it needs to first go through discussion on comp.lang.python. Also, you should find out how this would affect Jython and IronPython. -- Comment By: Chris Wilson (ciw42) Date: 2006-04-28 09:38 Message: Logged In: YES user_id=1018283 I see your point, and it's a good example of why using namespaces is so important, but in practice, with my proposal in place, the code you propose simply wouldn't compile. Assuming the compiler simply substituted the literal "3.1415" for "pi" as I've proposed, you'd end up with "3.1415 = 4", and a syntax error for trying to assign to a literal value. You'd not get as far as running the code, so in practice there'd be no issues with it running incorrectly. Being able to declare constants is important as it allows the compiler to make the sort of optimistations I mentioned previously. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-10 09:55 Message: Logged In: YES user_id=21627 The problem is that declaring the value assignment const doesn't help. Consider this: from math import pi def area(r): return r*r*pi pi = 4 print area(10) So even though math.pi might be declared as a constant, hard-coding its value into the function area would break this program - the value of the variable pi might change not change inside math, but it might change where it is imported. -- Comment By: Chris Wilson (ciw42) Date: 2006-04-06 17:59 Message: Logged In: YES user_id=1018283 I've re-opened this, as I don't feel it would be difficult to implement or require any fundamental changes to the parser or runtime. In fact, it would be very easy, and potentially very useful beyond the scope of my initial suggestion. Appologies to rhettinger if this seems rude, but I would ask that you give the following some consideration. The addition of a "const" or similar compiler directive would allow the compiler to simply do an on-the-fly substitution for the specified value/string etc. There would be no code analysis required, and adding this type of functionality would carry no real overheads or further complicate the compilation process. Ther
[ python-Feature Requests-1322308 ] itemgetter built-in?
Feature Requests item #1322308, was opened at 2005-10-10 05:56
Message generated for change (Comment added) made by collinwinter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1322308&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: capnSTABN (capnstabn)
Assigned to: Nobody/Anonymous (nobody)
Summary: itemgetter built-in?
Initial Comment:
uhm... operator.itemgetter() is useful and all, but fairly
retarded looking for how simple it is
basically what i am wrestling with at the moment is
doing some regular expressions without completely
ganking the crap out of the code to make it work, since
every freakin thing in re returns None all over the bloody
place like regular expressions were hitting a ragging
pinata with a chainsaw
after a LOT of muckymuck, basically six hours straight,
the simplest non-conditional form i could come up with
was this:
http://42.vg/81691";
target="_new">http://42.vg/81691
http://42.vg/81691
any comments would be leet!
--
>Comment By: Collin Winter (collinwinter)
Date: 2007-03-30 03:20
Message:
Logged In: YES
user_id=1344176
Originator: NO
None of the links provided work anymore, and I have no idea what is being
proposed (save for Raymond's comment). If the goal is to clarify the code
snippet supplied by the OP, I agree with Raymond: learn to use "if"
statements. Closing as "invalid".
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-11-14 07:19
Message:
Logged In: YES
user_id=80475
The use case is common enough to warrant further
exploration. Essentially what is being requested is a
straight-forward way to get a group dictionary that only
includes matching groups.
Two approaches come to mind.
1. Add a module constant, EXCLUDE, that when used as the
default value causes non-matching groups to be excluded from
the group dictionary:
d=mo.groupdict(re.EXCLUDE)
2. Create a new flag, N or NODEFAULT or (?N), indicating
that match objects should only include matching groups and
not create default entries for non-matches:
d=match('(?\w+)|(?\d+)', s, NODEFAULT).groupdict()
FWIW, am not sympathetic to the OP's code fragment not being
explicit. That is what happens when trying too hard to
avoid using an if-statement. The fragment is much clearer
without filtering:
for type, string_ in mo.groupdict().iteritems():
if string_ is not None:
. . .
--
Comment By: capnSTABN (capnstabn)
Date: 2005-10-11 05:33
Message:
Logged In: YES
user_id=1126596
ok to be more specific, as maybe that will help, line 17 in the
code:
for type, string_ in (filter(itemgetter(1), match.groupdict
().iteritems())):
is about as implicit as pulling a tooth to remove a strand of
celery
the problem is that when using a single expansive recursive
regular expression (which can translate an entire page of
HTML like in any WikiWiki system in microseconds) that the
amount of recursive calls because of all of the Nones flying
around gets ludicrous
a bit of a glimpse of a considerably more complex example:
http://generic-host.us/~kevin/display_renderer.png
please bear in mind that example is from 1999 or so
--
Comment By: capnSTABN (capnstabn)
Date: 2005-10-11 05:17
Message:
Logged In: YES
user_id=1126596
my request for enhancement is either a built-in version of
operation.itemgetter() or an alteration of the behavior of re
matches, i'm assuming the matter is up for debate so i wasn't
being specific.
this issue has nothing to do with showing code and i find your
followup to be completely off topic!
--
Comment By: Georg Brandl (birkenfeld)
Date: 2005-10-10 12:57
Message:
Logged In: YES
user_id=1188172
Please tell us what your request for enhancement is or I'm
going to close this as Invalid.
Sorry I'm not showing more respect for your writing
abilities :-), but if you want to show code around, do it on
comp.lang.python please.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1322308&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-1309676 ] Add os.path.relpath
Feature Requests item #1309676, was opened at 2005-09-30 14:38 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1309676&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: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Georg Brandl (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: Add os.path.relpath Initial Comment: Add a method to os.path which calculates the "difference" of two paths. See this python-dev thread for details and sample implementations: http://mail.python.org/pipermail/python-dev/2005-September/056391.html -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 03:21 Message: Logged In: YES user_id=1344176 Originator: NO Applied rbarran's patch as r54419. -- Comment By: Richard Barran (rbarran) Date: 2005-10-27 14:33 Message: Logged In: YES user_id=1207189 Hi, Submitted a patch #1339796 to add this function. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1309676&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-1177998 ] Add a settimeout to ftplib.FTP object
Feature Requests item #1177998, was opened at 2005-04-06 14:52 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1177998&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: Juan Antonio Valiño García (juanval) >Assigned to: Facundo Batista (facundobatista) Summary: Add a settimeout to ftplib.FTP object Initial Comment: It will be usefull that the FTP object of ftplib had a settimeout method to setup a timeout for the connection, because the only way of doing this is to use the socket.setdefaulttimeout method, and this is very dangerous when you are using threads. Thanks and keep up the work ! -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 03:23 Message: Logged In: YES user_id=1344176 Originator: NO Facundo, I believe you're doing something along these lines, right? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1177998&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-1110010 ] 'attrmap' function, attrmap(x)['attname'] == x.attname
Feature Requests item #1110010, was opened at 2005-01-26 11:28
Message generated for change (Comment added) made by collinwinter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&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: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'attrmap' function, attrmap(x)['attname'] == x.attname
Initial Comment:
One of the side effects of the new-style classes is that
objects don't necessarily have __dict__ attached to them.
It used to be possible to write things like
def __str__(self):
return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % self.__dict__
... but this doesn't work if the class doesn't have a
__dict__. Even if does, I'm not sure it will always get
members from base classes.
There is a 'vars' function; you could put 'vars(self)'
in the above instead of self.__dict__, but it still
doesn't work if
the class doesn't have a __dict__.
I can see different solutions for this:
(1) change the 'string %' operator so that it allows
%(.name)s, leading to a getattr() on the right-side
argument
rather than a getitem.
return "Node %(.name)s, %(.nlinks)d links,
active: %(.active)s" % self
(2) Make a builtin like vars, but which works when the
object doesn't have a __dict__ I.e. attrmap(x) would
return a mapping which is bound to x, and reading
attrmap(x)['attname'] is the same as
getattr(x,'attname'). Thus
return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % attrmap(self)
This attrmap() function can be implemented in pure
python, of course.
I originally thought (1) made a lot of sense, but (2) seems
to work just as well and doesn't require changing much.
Also, (1) allows cases like "%(name)s %(.name2)s",
which are not very useful, but are very likely to be
created by
accident; whereas in (2) you are deciding on the right
of the '%' whether you are naming attributes or
providing mapping keys.
I'm not sure it's a good idea change 'vars' to have
this behaviour, since vars(x).keys() currently works in
a predictable way when vars(x) works; whereas
attrmap(x).keys() may not be complete, or possible,
even when attrmap(x) is useful. I.e. when x has a
__getattr__ defined.
On the other hand, vars(x) doesn't currently do much at
all, so maybe it's possible to enhance it like this
without breaking anything.
The motivation for this came from the "%(name)s" issue,
but the attrmap() function would be useful in other
places e.g.
processdata( infile, outfile, **attrmap(options))
... where options might be obtained from optparse, e.g.
Or, an attrmap can be used with the new Templates:
string.Template('Node $name').substitute( attrmap(node))
Both of these examples will work with vars(), but only
when the object actually has __dict__. This is why
I'm thinking it may make sense to enhance vars: some
code may be broken by the change; but other code,
broken by new-style classes, may be unbroken by this
change.
The proxy could be writable, so that
attrmap(x)['a'] = y
is the same as
x.a = y
.. which could have more uses.
A possible useful (possibly weird) variation: attrmap
accepts 1 or more parameters, and the resulting
proxy is bound to all of them. when attrmap(x,y,z)['a']
is done, the proxy will try x.a, y.a, z.a until one of
them doesn't raise AttributeError. So it's equivalent
to merging dictionaries. This would be useful
in the %(name)s or Template cases, where you want
information from several objects.
--
>Comment By: Collin Winter (collinwinter)
Date: 2007-03-30 03:29
Message:
Logged In: YES
user_id=1344176
Originator: NO
Closing due to lack of support.
If you're still interested in an operator.attrmap() function, please try
and work up a patch to Modules/operator.c and resubmit.
--
Comment By: Gregory Smith (gregsmith)
Date: 2006-05-07 11:27
Message:
Logged In: YES
user_id=292741
I can't disagree with that -- one of the things I like about
python is that simple funcs I use fairly often can usually
be retyped out of my head in less time than it takes to find
them and copy them from another software project- and more
importantly, there's basically no risk that the fresh one
will be buggy, if it's expression is simple and clear.
So, the overhead of maintaining a zillion 'standard' utility
funcs outweighs the cost of having to recode them instead,
when they are small and simple. This applies as much to the
core library as it does to a site-specific library.
I do prefer if they have the same names each time I use them
though, since it makes it
[ python-Bugs-1688274 ] Python/C PyClass_* are not documented
Bugs item #1688274, was opened at 2007-03-26 14:24 Message generated for change (Comment added) made by tvainika You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&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 Private: No Submitted By: Tommi Vainikainen (tvainika) Assigned to: Nobody/Anonymous (nobody) Summary: Python/C PyClass_* are not documented Initial Comment: Python/C API Reference Manual chapter 7.5 Other Objects does not contain subchapter for Class objects, but only Instance objects and many other are documented there. >From header I can find that at least PyClass_Check and PyClass_New exist, I >just don't know what those do until I take time to read source code... :( -- >Comment By: Tommi Vainikainen (tvainika) Date: 2007-03-30 10:58 Message: Logged In: YES user_id=1753247 Originator: YES Looks good for me. Actually the first pointer to new-style classes is the most important I think... :) (which I found out by myself after reporting this bug) -- Comment By: Collin Winter (collinwinter) Date: 2007-03-30 06:24 Message: Logged In: YES user_id=1344176 Originator: NO Take a look at the attached patch and see if that says what you want. File Added: concrete.tex.diff -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
