[ python-Bugs-1239681 ] email.Utils.formatdate documetaion missing
Bugs item #1239681, was opened at 2005-07-17 12:09 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=1239681&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: Open Resolution: None Priority: 5 Submitted By: Nir Soffer (nirs) Assigned to: Nobody/Anonymous (nobody) Summary: email.Utils.formatdate documetaion missing Initial Comment: email.Utils.formatdate documentation does not mention that 'usegmt' keyword argument is new on Python 2.4. reference: http://python.org/doc/2.4.1/lib/module-email.Utils.html http://python.org/doc/2.3.5/lib/module-email.Utils.html I don't know if its the rule, but usually the docs warn about new additions, and its very important when you try to create code that should work on multiple Python versions. Suggested fix replace: "Optional usegmt is a flag that when True, outputs a date string with the timezone as an ascii string GMT, rather than a numeric -. This is needed for some protocols (such as HTTP). This only applies when localtime is False" with: "Optional usegmt is a flag that when True, outputs a date string with the timezone as an ascii string GMT, rather than a numeric -. This is needed for some protocols (such as HTTP). This only applies when localtime is False. New in Python 2.4." -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239681&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1239681 ] email.Utils.formatdate documetaion missing
Bugs item #1239681, was opened at 2005-07-17 04:09 Message generated for change (Settings changed) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239681&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: None Priority: 5 Submitted By: Nir Soffer (nirs) >Assigned to: Skip Montanaro (montanaro) Summary: email.Utils.formatdate documetaion missing Initial Comment: email.Utils.formatdate documentation does not mention that 'usegmt' keyword argument is new on Python 2.4. reference: http://python.org/doc/2.4.1/lib/module-email.Utils.html http://python.org/doc/2.3.5/lib/module-email.Utils.html I don't know if its the rule, but usually the docs warn about new additions, and its very important when you try to create code that should work on multiple Python versions. Suggested fix replace: "Optional usegmt is a flag that when True, outputs a date string with the timezone as an ascii string GMT, rather than a numeric -. This is needed for some protocols (such as HTTP). This only applies when localtime is False" with: "Optional usegmt is a flag that when True, outputs a date string with the timezone as an ascii string GMT, rather than a numeric -. This is needed for some protocols (such as HTTP). This only applies when localtime is False. New in Python 2.4." -- >Comment By: Skip Montanaro (montanaro) Date: 2005-07-17 06:50 Message: Logged In: YES user_id=44345 Fixed in 2.4 and CVS docs. Thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239681&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-414059 ] Floating point second in date/time tuple
Feature Requests item #414059, was opened at 2001-04-05 19:33 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414059&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: 3 Submitted By: Tim Cera (timcera) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point second in date/time tuple Initial Comment: Would like to have this: >>> time.localtime(1057035600.6) (2003, 7, 1, 1, 0.6, 0, 1, 182, 1) Instead of: >>> time.localtime(1057035600.6) (2003, 7, 1, 1, 0, 0, 1, 182, 1) At a minimum the fractional seconds should be rounded instead of truncated. thanks tim cera -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-09 10:06 Message: Logged In: YES user_id=80475 Agree with Brett. Closing this one. -- Comment By: Brett Cannon (bcannon) Date: 2003-05-13 00:55 Message: Logged In: YES user_id=357491 The problem is that the C library's localtime is used to do the conversion and that takes in a time_t argument. On almost all platforms this is a long int. Forcing the number to an integer prevent any unexpected warning about casting if the platform does support floats for some odd reason. The reason the argument is truncated is because the argument to PyArg_ParseTuple is 'd', which is integer. Python basically does what C would do which is truncate. You could round it up by taking the number as a Python object, calling Python's round function, and then extract the integer after the rounding. Trouble is that now your value accounts for time that you didn't even have. The plus side to truncating is your are not adding on time that did not occur; you are just losing some extra time you had. =). If you want to create a patch to rectify the situation you might get people to support the idea, but I don't view this as critical, especially when you can call round yourself before passing the value to localtime. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414059&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-445484 ] pickle lacks float('inf')
Feature Requests item #445484, was opened at 2001-07-28 17:21
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=445484&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: Fixed
Priority: 4
Submitted By: Anthony Doggett (anthonydoggett)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle lacks float('inf')
Initial Comment:
Support for float('inf') still appears to be missing in
Python 2.1.1 (#1, Jul 28 2001, 14:15:01)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)]
on linux2
>>> cPickle.dumps(float('inf'), 1)
Traceback (most recent call last):
File "", line 1, in ?
SystemError: frexp() result out of range
>>> pickle.dumps(float('inf'), 1)
Traceback (most recent call last):
File "", line 1, in ?
File "/var/ajd111/python/lib/python2.1/pickle.py",
line 943, in dumps
Pickler(file, bin).dump(object)
File "/var/ajd111/python/lib/python2.1/pickle.py",
line 109, in dump
self.save(object)
File "/var/ajd111/python/lib/python2.1/pickle.py",
line 211, in save
f(self, object)
File "/var/ajd111/python/lib/python2.1/pickle.py",
line 273, in save_float
self.write(BINFLOAT + pack('>d', object))
SystemError: frexp() result out of range
Both structmodule.c and cPickle.c require changes.
Surely something like
if (x == HUGE_VAL) {/* Inf */
e = 1024;
f = 0.0;
}
else {
f = frexp(x, &e);
...
and
if (e == 1024)
x = HUGE_VAL; /* Inf */
else {
is all that is required for all IEEE754 machines?
(structmodule.c requires similar changes for Float
also)
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-17 15:11
Message:
Logged In: YES
user_id=1188172
This is in CVS for 2.5.
--
Comment By: Tim Peters (tim_one)
Date: 2003-05-13 03:12
Message:
Logged In: YES
user_id=31435
This appears to be outside the scope of PEP 754 (as
defined by the PEP's author -- he's just aiming at symbolic
constants and inquiry functions).
--
Comment By: Brett Cannon (bcannon)
Date: 2003-05-13 02:46
Message:
Logged In: YES
user_id=357491
PEP 754 should make sure to deal with this.
--
Comment By: Tim Peters (tim_one)
Date: 2001-09-05 22:16
Message:
Logged In: YES
user_id=31435
Changed to Feature Request, and added to new "Non-
accidental 754 support" section of PEP 42.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 20:21
Message:
Logged In: YES
user_id=6380
Is there a point in keeping this bug report open
indefinitely? A "won't fix" would make just as much sense.
Maybe add Inf support to PEP 42.
--
Comment By: Tim Peters (tim_one)
Date: 2001-08-02 00:41
Message:
Logged In: YES
user_id=31435
Note that Python has no intentional support for Infs and
NaNs anywhere; even that float('inf') doesn't blow up when
you do it is a platform accident (it blows up ("invalid
literal") on my box).
Given that, in the absence of a comprehensive plan for
supporting this stuff across the board, and worker bees to
implement it, I downgraded the priority. A good plan would
refactor the code so that dealing with the platform double
and float formats occurs in only one place.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=445484&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-449227 ] rlcompleter add " (" to callables feature
Feature Requests item #449227, was opened at 2001-08-08 20:04
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449227&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: Open
Resolution: None
Priority: 5
Submitted By: Roman Suzi (rnd0110)
Assigned to: Nobody/Anonymous (nobody)
Summary: rlcompleter add "(" to callables feature
Initial Comment:
I use rlcompleter extensively in interactive Python
mode.
I think it could be cool if callable objects were added
"("
when completed. This way it will be much faster to
program, without looking-up __doc__. For example:
>>> f.fil
will give:
>>> f.fileno(_
("_" is to mark cursor position)
and:
>>> f.so
will (as before) give:
>>> f.softspace _
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-17 15:15
Message:
Logged In: YES
user_id=1188172
Any comments on this one? Sounds reasonable to me.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449227&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1239186 ] Install Error: "cannot compute sizeof (int), 77"
Bugs item #1239186, was opened at 2005-07-15 18:00 Message generated for change (Comment added) made by rgazzale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239186&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bob Gazzale (rgazzale) Assigned to: Nobody/Anonymous (nobody) Summary: Install Error: "cannot compute sizeof (int), 77" Initial Comment: Computer: Mac OS: Tiger 10.4.2 When attempting to install Python 2.4, I get the following error message in the "configure" stage: "checking size of int... configure: error: cannot compute sizeof (int), 77" config.log is attached. Many thanks, Bob -- >Comment By: Bob Gazzale (rgazzale) Date: 2005-07-17 09:48 Message: Logged In: YES user_id=1313508 I am using the gcc I downloaded from Gaurav Khanna's HPC site. Thanks for the lead. I'll try going back to a non-experimental version of gcc. Bob -- Comment By: Brett Cannon (bcannon) Date: 2005-07-15 18:23 Message: Logged In: YES user_id=357491 Are you using the standard version of gcc that comes with Tiger? I noticed in the log it says ``gcc (GCC) 4.1.0 20050517 (experimental)`` and I thought Tiger had gcc 4.0 (I can't check right now since I am at work), let alone came with a non-experimental version. Regardless, I don't see how it could be the configure files fault since Python does not have any control over the C compiler being able to determine the size of int. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239186&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-567972 ] Missing 4 socket object properties
Feature Requests item #567972, was opened at 2002-06-12 13:56
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
>Assigned to: Martin v. Löwis (loewis)
Summary: Missing 4 socket object properties
Initial Comment:
The C socketmodule has a struct PySocketSockObject,
with family, type and proto members.
These would be terribly helpful to have access to in
Python, when implementing some generic socket helper
functions.
The "blocking" flag could also be made available, but
would require some extra coding.
(I'm using Python 2.1.3 under Linux 2.4.16, so I cannot
extend the socket class itself ((as in py2.2)), and don't
want to slow down sockets with a complete wrapper, as I
use them heavily.)
Thanks, Graham.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-17 15:49
Message:
Logged In: YES
user_id=1188172
Attaching a patch which implements the three members of
_socket.socket.
Please review.
--
Comment By: Martin v. Löwis (loewis)
Date: 2002-06-15 15:21
Message:
Logged In: YES
user_id=21627
Sounds good. Would you like to produce a patch implementing
this feature?
--
Comment By: Graham Horler (grahamh)
Date: 2002-06-12 14:00
Message:
Logged In: YES
user_id=543663
Oh yes, the repr of a socket object includes the missing info,
so to get hold of the family, I go:
int(repr(sock).split(' ')[3].split('=')[1][:-1])
Similar for type and protocol, not nice!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&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-739029 ] Constructor for counting things
Feature Requests item #739029, was opened at 2003-05-17 04:22
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=739029&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: Open
Resolution: None
Priority: 5
Submitted By: David Albert Torpey (dtorp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Constructor for counting things
Initial Comment:
Counting things is very common. May I suggest an
alternate dictionary constructor that works like this:
class BetterDictionary(dict):
def bag(classobject, sequence):
"Fast way to count things"
b = classobject()
for k in sequence:
b[k] = b.get(k,0) + 1
return b
bag = classmethod(bag)
print BetterDictionary.bag("jack and jill went up a
hill ...")
A C implementation could do this very fast.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-17 16:07
Message:
Logged In: YES
user_id=1188172
Perhaps "bag" is a good addition to the "collections" module.
--
Comment By: David Albert Torpey (dtorp)
Date: 2003-08-26 20:07
Message:
Logged In: YES
user_id=681258
Smalltalk has a collection class called Bag that fills the same
role. It is a frequently used class.
The current way of doing things is too slow. Disassembly
shows that the whole process involves loading a constant for
1, loading a constant for zero, loading the local variable 'b',
performing an attribute lookup for 'get', loading the local
variable 'k', calling 'get', running the summation, re-loading
both 'b' and 'k' and doing a subscript store. Along the way,
there are two dictionary lookups for the same key. All of
that is just the inner loop and is wrapped in for-loop with all
of its overhead. Instead, the whole thing could be done in
one step at C speed: b.bag(itemlist).
--
Comment By: Brett Cannon (bcannon)
Date: 2003-08-12 08:12
Message:
Logged In: YES
user_id=357491
I don't know if it is *that* common. Besides, as your code shows,
it isn't that complex. It strikes me as a little too specific to be
made a built-in dict constructor.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=739029&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-778763 ] Optional type enforcement
Feature Requests item #778763, was opened at 2003-07-28 08:18 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=778763&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Postponed Priority: 5 Submitted By: Matt Perry (occupant4) Assigned to: Nobody/Anonymous (nobody) Summary: Optional type enforcement Initial Comment: One of the things that makes Python easy to code in is the fact that you don't have to explicitly declare the types of variables, or associate a specific type with a variable. However, this can potentially lead to somewhat confusing and hard-to-maintain code, not to mention make it easier to introduce bugs. An idea struck me that it might be possible to combine the power and safety of a strictly type-checked language with the speed and ease of coding of Python. Normal variables as they stand now would be unaffected by this feature, and retain their polymorphic type capabilities. Allow the programmer to optionally declare the type of a variable somehow, be it with the C-like syntax "int x", or Pascal's (I think?) "x: int", or a new syntactic representation. Python could then issue a TypeError if the program attempts to assign a non-int to x. Obviously this feature could apply to any data type, such as string, list, or perhaps user-defined classes. Class member variables can be declared as now in the class definition body, with the same syntax to specify a type, ie: class Test: int x = 5 string name = "test" untyped = None In addition, adding a type specifier to a function's parameters could serve another means of distinguishing it from other functions, which could allow function overloading, ie: def double(int x): return 2*x def double(string x): return x + ' ' + x Advantages: - clarifies the author's intention in writing code, and could help prevent confusion as to what type a variable/parameter is. - helps prevent bugs due to type mistakes - doesn't interfere with existing code or coding style, as dynamically typed variables are still allowed - could allow function overloading if it was wanted Disadvantages: - implementing a type checker could be difficult? - potentially pollutes namespace with extra keywords like 'string' or 'list'. may need to choose different keywords. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 16:12 Message: Logged In: YES user_id=1188172 This isn't going to be in Python 2.x, but presumably in Python 3k, so I'm closing it for now. (A change in 2.x would at least require a PEP) -- Comment By: Armin Rigo (arigo) Date: 2004-05-21 18:25 Message: Logged In: YES user_id=4771 This idea has always been considered but there are very deep issues with it. You should give a look to Pyrex, whose language a more static and type-checked version of Python. It produces C extension modules for the regular Python interpreter, so it can be mixed with regular Python code easily. google:python+pyrex -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-05 13:52 Message: Logged In: YES user_id=80475 To make the most of polymorphism, interface checking would be preferable to enforcing specific types. For example, it is better to check that f is a filelike type rather than requiring that is actually be a file -- that way, StringIO objects can be substituted without breaking code. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=778763&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-567972 ] Missing 4 socket object properties
Feature Requests item #567972, was opened at 2002-06-12 13:56
Message generated for change (Settings changed) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&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: 7
Submitted By: Graham Horler (grahamh)
Assigned to: Martin v. Löwis (loewis)
Summary: Missing 4 socket object properties
Initial Comment:
The C socketmodule has a struct PySocketSockObject,
with family, type and proto members.
These would be terribly helpful to have access to in
Python, when implementing some generic socket helper
functions.
The "blocking" flag could also be made available, but
would require some extra coding.
(I'm using Python 2.1.3 under Linux 2.4.16, so I cannot
extend the socket class itself ((as in py2.2)), and don't
want to slow down sockets with a complete wrapper, as I
use them heavily.)
Thanks, Graham.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-17 15:49
Message:
Logged In: YES
user_id=1188172
Attaching a patch which implements the three members of
_socket.socket.
Please review.
--
Comment By: Martin v. Löwis (loewis)
Date: 2002-06-15 15:21
Message:
Logged In: YES
user_id=21627
Sounds good. Would you like to produce a patch implementing
this feature?
--
Comment By: Graham Horler (grahamh)
Date: 2002-06-12 14:00
Message:
Logged In: YES
user_id=543663
Oh yes, the repr of a socket object includes the missing info,
so to get hold of the family, I go:
int(repr(sock).split(' ')[3].split('=')[1][:-1])
Similar for type and protocol, not nice!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1223238 ] race in os.makedirs()
Bugs item #1223238, was opened at 2005-06-18 18:37 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mattias Engdegård (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: race in os.makedirs() Initial Comment: os.makedirs() can fail if one of its components is created while it is running (perhaps by another process). This is because it checks for each directory if it exists before creating it. This is bad programming style. A correct implementation would just call mkdir() on each directory (starting with the rightmost, probably) and ignoring any EEXIST error. This would not only fix the bug, it would also be faster (fewer syscalls). The patch is simple, but there is a wart in the design: os.makedirs() throws an error if the (rightmost) directory already exists, although by calling this function the user has clearly indicated that she wants the directories to be created if they don't exist and have no complaints otherwise. This leads to code like: try: os.makedirs(path) except OSError: pass which is doubly bad because it hides the race condition! So, before I submit a patch, should we: a) just fix this bug but keep the old design b) fix this bug, and don't throw an error if the dir exists or maybe do a) for the next 2.4.x bugfix release and b) in 2.5? -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 21:56 Message: Logged In: YES user_id=1188172 See patch #1239890. -- Comment By: Mattias Engdegård (yorick) Date: 2005-06-25 23:11 Message: Logged In: YES user_id=432579 I'm fine with fixing the design for 2.5 and ignoring the bug for 2.4, since programs susceptible to the bug must use some kind of work-around in 2.4.x (x < 2) anyway. What I am using right now is: def makedirs(name, mode=0777): try: os.mkdir(name, mode) return except OSError, err: if err.errno == errno.EEXIST: return if err.errno != errno.ENOENT: raise makedirs(os.path.dirname(name), mode) makedirs(name, mode) This is compact and elegant, but relies on mkdir producing the correct errno values, which should be true for all platforms I'm aware of. It could also theoretically loop infinitely in bizarre cases but I don't see how that ever could happen. -- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-18 19:43 Message: Logged In: YES user_id=35752 I vote to fix the design for 2.5. Backporting the minimal fix to 2.4 would be optional, IMO. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1061920 ] "k" specifier in PyArg_ParseTuple incomplete documentated
Bugs item #1061920, was opened at 2004-11-07 15:28 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061920&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.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gustavo J. A. M. Carneiro (gustavo) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: "k" specifier in PyArg_ParseTuple incomplete documentated Initial Comment: Documentation for python 2.3 says: "k" (integer) [unsigned long] Convert a Python integer to a C unsigned long without overflow checking. New in version 2.3. However I was told -- and tested to be true -- that "k" also accepts python long as argument. This should be mentioned in the documentation, otherwise programmers will assume "k" only accepts values in the range 0-2^31, thus not allowing the full 'unsigned long' range. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:05 Message: Logged In: YES user_id=1188172 Fixed as Doc/api/utilities.tex r1.22, r1.20.2.2. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061920&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1015140 ] "article id" in description of NNTP objects
Bugs item #1015140, was opened at 2004-08-24 12:26 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015140&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Felix Wiemann (felixwiemann) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: "article id" in description of NNTP objects Initial Comment: lib/nntp-objects.html uses the term "article id" several times. This term is ambiguous though. Either "article number" or "message id" should be used. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:27 Message: Logged In: YES user_id=1188172 Corrected in docs and docstrings as Lib/nntplib.py r1.40, r1.39.2.1 Doc/lib/libnntplib.tex r1.33, r1.32.2.1 -- Comment By: Felix Wiemann (felixwiemann) Date: 2004-08-30 22:13 Message: Logged In: YES user_id=1014490 > Patches are welcome. I don't have enough time (and I don't care enough) to write a patch for this, currently. > If you have a link to authoritive > guidance, that would be nice also. The only occurence of the case-insensitive regex 'article.id' in all RFCs is in RFC 977, which says: 223 n a article retrieved - request text separately (n = article number, a = unique article id) (Here, it probably means message-id.) There are frequent occurences of 'article number' and 'message-id' in the NNTP related RFCs 977 and 2980. So 'article id' probably should be avoided, as it is ambiguous. (The docs sometimes use it in the sense of 'message-id' and sometimes as 'article number', from what I could see.) -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-29 10:20 Message: Logged In: YES user_id=80475 Patches are welcome. If you have a link to authoritive guidance, that would be nice also. -- Comment By: Felix Wiemann (felixwiemann) Date: 2004-08-29 10:11 Message: Logged In: YES user_id=1014490 Same problem for the docstrings in the source file Lib/nntplib.py. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015140&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1014761 ] Missing urllib.urlretrieve docs
Bugs item #1014761, was opened at 2004-08-24 00:05 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014761&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: Missing urllib.urlretrieve docs Initial Comment: urllib.urlretrieve docs give no description for the reporthook argument -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:31 Message: Logged In: YES user_id=1188172 Actually, they do, in the second paragraph of the urlretrieve docs. Closing as Invalid. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014761&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1099363 ] refman doesn't know about universal newlines
Bugs item #1099363, was opened at 2005-01-10 11:33 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099363&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: refman doesn't know about universal newlines Initial Comment: The reference manual (in ref/ref2.tex) still talks about the various different end-of-line conventions, but as Python reads source code with universal newlines this is no longer relevant. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:35 Message: Logged In: YES user_id=1188172 This is already fixed since revision 1.57 of ref2.tex. Thanks for the report, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099363&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-912943 ] 7.5.6 Thread Objects is too vague
Bugs item #912943, was opened at 2004-03-09 20:16 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=912943&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: 7.5.6 Thread Objects is too vague Initial Comment: Some items which could be improved "Once the thread's activity is started, the thread is considered 'alive' and 'active' (these concepts are almost, but not quite exactly, the same; their definition is intentionally somewhat vague)." This is a bit silly. Either these attributes are intended to be exposed to users or they're not. If they are, they should be well defined. If not, they shouldn't be mentioned at all. "If the subclass overrides the constructor, it must make sure to invoke the base class constructor (Thread.__init__()) before doing anything else to the thread." This is misleading. You need to call "Thread.__init__ (self)", i.e. pass along the self argument. At least I think you do :-) "join([timeout]) ... When the timeout argument is present and not None, it should be a floating point number specifying a timeout for the operation in seconds (or fractions thereof)." What happens if you pass None? Does it wait forever? Is this any different from not passing any argument at all? What happens if a timeout occurs? Is there any way to differentiate between a timeout and a normal return? "A thread can be join()ed many times." Presumably only if all but the last call timed out? Or maybe not? If you get a normal return (i.e. not a timeout) from join(), and then call join() again, what happens? Does it just return immediately with no error? -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 23:01 Message: Logged In: YES user_id=1188172 The second item is no bug. Methods in the docs are always written with a trailing "()". I have addressed the join() issues in Doc/lib/libthreading.tex r1.22, r1.20.4.2. Closing as the remaining issue is covered by the patch mentioned by alanvgreen. -- Comment By: Alan Green (alanvgreen) Date: 2005-01-23 06:46 Message: Logged In: YES user_id=1174944 Submitted Patch 1107656 which addresses the 'alive' and 'active' issue. It does this by deprecating the isAlive() method and adding an isActive method instead. The patch also updates the documentation to talk about threads being 'active' rather than 'alive and active'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=912943&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1223238 ] race in os.makedirs()
Bugs item #1223238, was opened at 2005-06-18 19:37 Message generated for change (Comment added) made by nirs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mattias Engdegård (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: race in os.makedirs() Initial Comment: os.makedirs() can fail if one of its components is created while it is running (perhaps by another process). This is because it checks for each directory if it exists before creating it. This is bad programming style. A correct implementation would just call mkdir() on each directory (starting with the rightmost, probably) and ignoring any EEXIST error. This would not only fix the bug, it would also be faster (fewer syscalls). The patch is simple, but there is a wart in the design: os.makedirs() throws an error if the (rightmost) directory already exists, although by calling this function the user has clearly indicated that she wants the directories to be created if they don't exist and have no complaints otherwise. This leads to code like: try: os.makedirs(path) except OSError: pass which is doubly bad because it hides the race condition! So, before I submit a patch, should we: a) just fix this bug but keep the old design b) fix this bug, and don't throw an error if the dir exists or maybe do a) for the next 2.4.x bugfix release and b) in 2.5? -- Comment By: Nir Soffer (nirs) Date: 2005-07-18 00:10 Message: Logged In: YES user_id=832344 current 2.4 code does not return an error if the directory exists, the patch must not change that behavior. It will not be a good idea to change that behavior in 2.5 or any version, it can break lot of code. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:56 Message: Logged In: YES user_id=1188172 See patch #1239890. -- Comment By: Mattias Engdegård (yorick) Date: 2005-06-26 00:11 Message: Logged In: YES user_id=432579 I'm fine with fixing the design for 2.5 and ignoring the bug for 2.4, since programs susceptible to the bug must use some kind of work-around in 2.4.x (x < 2) anyway. What I am using right now is: def makedirs(name, mode=0777): try: os.mkdir(name, mode) return except OSError, err: if err.errno == errno.EEXIST: return if err.errno != errno.ENOENT: raise makedirs(os.path.dirname(name), mode) makedirs(name, mode) This is compact and elegant, but relies on mkdir producing the correct errno values, which should be true for all platforms I'm aware of. It could also theoretically loop infinitely in bizarre cases but I don't see how that ever could happen. -- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-18 20:43 Message: Logged In: YES user_id=35752 I vote to fix the design for 2.5. Backporting the minimal fix to 2.4 would be optional, IMO. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-872769 ] os.access() documentation should stress race conditions
Bugs item #872769, was opened at 2004-01-08 02:40 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872769&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: seth arnold (setharnold) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: os.access() documentation should stress race conditions Initial Comment: Every version of the documentation I've seen associated with the os.access() function neglects to mention that its use is almost always a security vulnerability. For the versions of python that are still maintained, I'd like to see the documentation for this function expanded to include a paragraph very similar to the warning given in my system's access(2) manpage: Using access to check if a user is authorized to e.g., open a file before actually doing so using open(2) creates a security hole, because the user might exploit the short time interval between checking and opening the file to manipulate it. (This paragraph comes from a Debian system; if it is more work to validate the license on this manpage for including this paragraph here, I'd be happy to write some new content under whatever license is required to get a warning included.) Of course, there are web-based documents derived from the module's built-in documentation. It'd be keen if whoever fixes this in the module could poke the website document maintainer and ask them to regenerate the content. Thanks! -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 23:10 Message: Logged In: YES user_id=1188172 Thanks for the suggestion. Committed as Doc/lib/libos.tex r1.163, r1.146.2.9. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872769&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1021621 ] use first_name, not first, in code samples
Bugs item #1021621, was opened at 2004-09-03 07:27 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021621&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: Feature Request >Status: Closed >Resolution: Fixed Priority: 1 Submitted By: Steve R. Hastings (steveha) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: use first_name, not first, in code samples Initial Comment: Low priority documentation request. I'm studying the documentation on how to write a C module. http://docs.python.org/ext/node22.html Please update the sample code in the documentation to use "first_name" rather than "first" and "last_name" rather than "last". When I first studied the code and saw "first" and "last" members in a structure, I thought those were for a linked list of some sort. Much later in the code I realized that the object was supposed to have a first name and a last name, and there was no linked list at all. "first_name" would be much more self-documenting than "first". An acceptable alternative would be a comment after the "first" declaration, saying: /* first name */ This is a small point, but I think it would be an improvement to the documentation. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 23:20 Message: Logged In: YES user_id=1188172 While mwh's new docs are in the making, I added the comments you suggested as Doc/ext/noddy2.c r1.5.4.1, r1.6. -- Comment By: Michael Hudson (mwh) Date: 2004-09-03 12:59 Message: Logged In: YES user_id=6656 FWIW, I agree. I'm attempting to rewrite the extending and embedding manual, and yes, this is one of the things I've changed. I've just uploaded my latest draft to http://starship.python.net/crew/mwh/toext/ which gets a little way into the area of defining new types. I'd really appreciate your comments! (to [EMAIL PROTECTED], please). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021621&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1239948 ] distutils: MetroWerks support can go
Bugs item #1239948, was opened at 2005-07-17 23:44 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=1239948&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Anthony Baxter (anthonybaxter) Summary: distutils: MetroWerks support can go Initial Comment: I'm not sure how far back the current distutils (i.e. the one from the CVS trunk) is supposed to be backward compatible, but from 2.4 onwards Python does not support Mac OS 9 anymore, and therefore support for the MetroWerks C compiler can be ripped out. Theoretically there's an MW compiler on windows too, but nobody uses it and the mwerkscompiler object in distutils currently only support the Mac compiler. And actually only that in the exact way that MacPython used it. I'm basically asking for an opinion here: is it a good idea to rip mwerkscompiler out. Feel free to assign back to me to do the work. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239948&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1217591 ] make frameworkinstall fails for non-default location
Bugs item #1217591, was opened at 2005-06-09 16:54
Message generated for change (Comment added) made by jackjansen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217591&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: Macintosh
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Mitch Chapman (mitchchapman)
Assigned to: Jack Jansen (jackjansen)
Summary: make frameworkinstall fails for non-default location
Initial Comment:
Mac OS X 10.3.8, Python 2.4.1. Attempts to 'make
frameworkinstall' to a non-default prefix and framework location fail:
$ ./configure --prefix=
--enable-framework=/Frameworks
$ make
$ make frameworkinstall
The last step always attempts to create /usr/local/bin/python,
instead of /bin/python.
The immediate cause appears to be line 20 of
Mac/OSX/Makefile:
bindir=/usr/local/bin
The problem is easier to spot if the 'make frameworkinstall' step is
performed without root permissions:
$ ./configure --prefix=${HOME}/tmp/py241 --enable-
framework=${HOME}/tmp/py241/Frameworks
...
$ make
...
$ make frameworkinstall
...
make -f ./Mac/OSX/Makefile installunixtools DIRMODE=755 FILEMODE=644
srcdir=. builddir=. DESTDIR= prefix=/Users/myself/tmp/py241/
Frameworks/Python.framework/Versions/2.4
/usr/bin/install -c -d /usr/local/bin
install: chmod 755 /usr/local/bin: Operation not permitted
ln -fsn /Users/myself/tmp/py241/Frameworks/Python.framework/
Versions/2.4/bin/python /usr/local/bin/python2.4
ln: /usr/local/bin/python2.4: Permission denied
make[1]: *** [installunixtools] Error 1
make: *** [frameworkinstallunixtools] Error 2
--
>Comment By: Jack Jansen (jackjansen)
Date: 2005-07-17 23:57
Message:
Logged In: YES
user_id=45365
The bad news is that this is difficult to fix: the whole "frameworkinstall"
sequence is a bit of a hack, and it works by overriding prefix to point
into the bowels of the framework and then doing the equivalent of a
"make install".
The good news is that if I understand correctly what you're trying to do,
building to a staging area so you can package things for distribution
later, there's another way to do this that does work: use the DESTROOT
environment variable. If you do "DESTROOT=/tmp/py241 configure --
enable-frameworks" you'll get a tree ready for installation in /tmp/py241.
But that assumes you can live with /tmp/py241/usr/local/bin.
If your needs are different reopen the bug and explain your use case and
I'll think harder about a solution:-)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217591&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1238681 ] freed pointer is used in longobject.c:long_pow()
Bugs item #1238681, was opened at 2005-07-15 01:06
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238681&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Luke (luked)
Assigned to: Tim Peters (tim_one)
Summary: freed pointer is used in longobject.c:long_pow()
Initial Comment:
See in the following code snippet (from the end of the
long_pow function in longobject.c) that "b" is used
after it has been freed:
Done:
Py_XDECREF(a);
Py_XDECREF(b);
Py_XDECREF(c);
Py_XDECREF(temp);
if (b->ob_size > FIVEARY_CUTOFF) {
for (i = 0; i < 32; ++i)
Py_XDECREF(table[i]);
}
return (PyObject *)z;
}
The error exists in 2.4.1 and on CVS trunk.
--
>Comment By: Tim Peters (tim_one)
Date: 2005-07-17 19:47
Message:
Logged In: YES
user_id=31435
Eww -- gross. Thanks for the report! Repaired (along with a
another long_pow() coding error) in:
Misc/NEWS 1.1319
Objects/longobject.c 1.169
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-07-15 01:26
Message:
Logged In: YES
user_id=80475
Tim, I believe this one belongs to you (checkin 1.163 on
8/30/2004).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238681&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
