[ python-Bugs-1390605 ] time docs lack %F in strftime!
Bugs item #1390605, was opened at 2005-12-26 16:58
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=1390605&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nikos Kouremenos (nkour)
Assigned to: Nobody/Anonymous (nobody)
Summary: time docs lack %F in strftime!
Initial Comment:
time.strftime('%F', t)
'2005-12-26'
but docs hide it
they may hide more ;( :(
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390605&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1390608 ] split() breaks no-break spaces
Bugs item #1390608, was opened at 2005-12-26 17:03 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=1390608&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: MvR (maxim_razin) Assigned to: Nobody/Anonymous (nobody) Summary: split() breaks no-break spaces Initial Comment: string.split(), str.split() and unicode.split() without parameters break strings by the No-break space (U+00A0) character. This character is specially intended not to be a split border. >>> u"Hello\u00A0world".split() [u'Hello', u'world'] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1390629 ] time.strftime('%F', local_time) is okay but time.strptime no
Bugs item #1390629, was opened at 2005-12-26 17:28
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=1390629&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Nikos Kouremenos (nkour)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime('%F', local_time) is okay but time.strptime no
Initial Comment:
THIS IS SUPER HUGE IMO
>>> a = time.strftime('%F', local_time)
>>> time.strptime(a, '%F')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/_strptime.py", line 287, in
strptime
format_regex = time_re.compile(format)
File "/usr/lib/python2.4/_strptime.py", line 264, in
compile
return re_compile(self.pattern(format), IGNORECASE)
File "/usr/lib/python2.4/_strptime.py", line 256, in
pattern
processed_format = "%s%s%s" % (processed_format,
KeyError: 'F'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390629&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1355842 ] Incorrect Decimal-float behavior for += and *=
Bugs item #1355842, was opened at 2005-11-13 11:17
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&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: Connelly (connelly)
Assigned to: Facundo Batista (facundobatista)
Summary: Incorrect Decimal-float behavior for += and *=
Initial Comment:
The += and *= operators have strange behavior when the
LHS is a Decimal and the RHS is a float (as of
2005-11-13 CVS decimal.py).
Example:
>>> d = Decimal('1.02')
>>> d += 2.1
>>> d
NotImplemented
A blatant violation of "Errors should never pass silently."
Also, a bad error description is produced for the *=
operator:
>>> d = Decimal('1.02')
>>> d *= 2.9
Traceback (most recent call last):
File "", line 1, in ?
TypeError: can't multiply sequence by non-int
--
>Comment By: Armin Rigo (arigo)
Date: 2005-12-26 16:31
Message:
Logged In: YES
user_id=4771
See proposed patch: #1390657
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-12-22 21:31
Message:
Logged In: YES
user_id=38388
Hi Facundo,
the problem you are seeing seems to be in the way new-style
classes implement number coercion.
Apparently some part in the (not so new-style anymore)
coercion logic is masking an exception which then triggers
later during processing.
The NotImplemented singleton should never make it to the
interactive shell since it is normally only used internally
by the number coercion logic to signal "object method
doesn't handle mixed type operation".
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-12-22 17:10
Message:
Logged In: YES
user_id=752496
Regarding problem 1:
Nick also detected this behaviour, back in March
(http://mail.python.org/pipermail/python-dev/2005-March/051834.html),
in python-dev discussions about how integrate better the
Decimal behaviour into Python framework.
Even knowing this, Raymond Hettinger and I made a patch
(almost exactly the same), and corrected another behaviour.
Will this issue be resolved somewhen? Raymond said that this
problem is also present in sets.py and datetime objects
(http://mail.python.org/pipermail/python-dev/2005-March/051825.html),
and that should be addressed in a larger context than decimal.
As Neil Schemenauer proposed
(http://mail.python.org/pipermail/python-dev/2005-March/051829.html),
Decimal now returns NotImplemented instead of raise
TypeError, which should be the correct way to deal with
operation capabilities in the numbers.
And look at this:
>>> d
Decimal("1") # using decimal.py rev. 39328 from svn
>>> d + 1.2
Traceback (most recent call last):
File "", line 1, in ?
TypeError: unsupported operand type(s) for +: 'Decimal' and
'float'
>>> d += 1.2
>>> d
NotImplemented
>>>
Why this happens? Really don't know, it's beyond my actual
knowledge, I'll keep searching. But I'm not so sure that
this is a Decimal issue.
Regarding problem 2:
I'll fix that.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-22 05:52
Message:
Logged In: YES
user_id=33168
Facundo, can you look into this? Are you still working on
Decimal?
--
Comment By: Connelly (connelly)
Date: 2005-12-02 06:17
Message:
Logged In: YES
user_id=1039782
The += and *= operations also give the same strange behavior
when the LHS is a Decimal and the RHS is str or unicode:
>>> d = Decimal("1.0")
>>> d += "5"
>>> d
NotImplemented
>>> d = Decimal("1.0")
>>> d *= "1.0"
Traceback (most recent call last):
File "", line 1, in ?
TypeError: can't multiply sequence by non-int
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-14 04:43
Message:
Logged In: YES
user_id=33168
Hmmm. __add__ returns NotImplemented which works with
classic classes, but not new-style classes. I wonder if
NotImplementedError is supposed to be raised for new-style
classes.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-729913 ] metaclasses, __getattr__, and special methods
Bugs item #729913, was opened at 2003-04-29 23:57 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729913&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: Type/class unification Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) Assigned to: Nobody/Anonymous (nobody) Summary: metaclasses, __getattr__, and special methods Initial Comment: __getattr__ on metaclasses aren't called when it would seem "logical"for it to be. E.g.: >>> class meta(type): ... def __getattr__(cls, name): ... if name == '__len__': ...print "meta.__getattr__('__len__')" ...return lambda: 42 ... else: ...print 'meta.__getattr__', name ...return name ... >>> class S(object): ... __metaclass__ = meta ... >>> S.__len__() meta.__getattr__('__len__') 42 >>> len(S) Traceback (most recent call last): File " ", line 1, in ? TypeError: len() of unsized object >>> I was told that special method "foo(x, arg)" was implemented as "type(x).__foo__(x, arg)", which doesn't seem to be the case always... Compare: >>> class meta(type): ... def __len__(cls): ... return 42 ... >>> class S(object): ... __metaclass__ = meta ... >>> S.__len__() 42 >>> len(S) 42 >>> So, it looks like it's looking up __len__ in the metaclass, but not falling back on __getattr__ when it isn't there? I've looked at the C code and it seems like special methods each have their own way of finding the function they're needing. >From Alex Martelli: Ah yes, I see now! Yes, functions such as len() rely on slots in the type object, e.g. as you've noticed: > finding the function they're needing, e.g. for len, it looks like it > uses: > > m = o->ob_type->tp_as_sequence; > if (m && m->sq_length) > return m->sq_length(o); > > return PyMapping_Size(o); and the "incredibly complex thinking" (quoting from typeobject.c) in update_one_slot doesn't seem to work except for operations the which "the class overrides in its dict" (again from a comment in typeobject.c, this one for fixup_slot_dispatchers). The issue may be with _PyType_Lookup (again in the same ,c file), which just gives up if it can't find a name somewhere along the mro (it doesn't "look upwards" to the metaclass) while type_getattro DOES work upwards on the metaclass too. H. I'm not sure I really understand all that's going on here - it IS a rather hairy zone of the code. Maybe you can post this as a bug in 2.3 beta 1 on sourgeforge (ideally showing where in the docs it defines the semantics that it then doesn't respect) so we can get this looked at by the few people who really DO grasp these parts...;- ). There is probably some sound implementation reason for the current behavior, but if so it should be better documented, I think. Back to me: The point being that I haven't found any place in the documentation that defines what the attribute lookup is on new-style classes (and the C code is too hairy for me to understand :-) As a special case of this problem, super() can't create an object which intercepts the special methods like it does for other methods, e.g.: super(MyCls, self).__getitem__(5) works, but not super(MyCls, self)[5] I don't know if that is intended or not, but it's not documented, though neither is exactly _what_ super is? (i.e. it looks like it's an object, that when you call a method, 'm', on it, uses the superclass method 'm', but the subclass versions of all other methods, although as above, not in all contexts, and I'm not sure whether you're supposed to be able to treat it as a first class object [pass as arg, return, etc]) -- bjorn -- >Comment By: Armin Rigo (arigo) Date: 2005-12-26 17:13 Message: Logged In: YES user_id=4771 This is a known documentation bug: all this is expected, but under-documented. Indeed, len(x) calls the special method __len__ of 'x', but what is not specified is the real definition of "calling a special method" on an object 'x': it is to look up the name "__len__" in the dict of type(x), then in the dict of the parent types in MRO order. It's really not the same thing as an attribute lookup. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-10-01 13:43 Message: Logged In: YES user_id=1188172 I closed #789262 as a duplicate of this one. More info may be there. -- Comment By: Michael Hudson (mwh) Date: 2004-11-15 07:20 Message: Logged In: YES user_id=6656 You could try http://starship.python.net/crew/mwh/hacks/oop-after-python2
[ python-Bugs-1066490 ] special methods become static
Bugs item #1066490, was opened at 2004-11-15 06:46 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066490&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: Type/class unification Group: Python 2.3 >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Kevin Quick (kquick) Assigned to: Michael Hudson (mwh) Summary: special methods become static Initial Comment: This *may* be a duplicate of 729913, but there's either additional info here, or this is actually different. The issue is that any special method (e.g. __call__, __str__, etc.) defined for a new-style (i.e. object-based) class seems to be static (i.e. unchangeable) with some special lookup applied for that method, but this doesn't seem to be the case for regular methods. class A: def foo(self): return 1 def __call__(self): return 2 def bar(self): return 3 def adjust(self): self.foo = self.bar self.__call__ = self.bar a = A() print a.foo(), a() a.adjust() print a.foo(), a() Will print: 1 2 3 3 But if the A is turned into a new-style class by changing the first line: class A(object): then the printed results are: 1 2 3 2 To the best of my understanding of the migration from classic classes to new-style classes (and metaclassing), this shouldn't occur. I have also tried various name munging for the special method (e.g. setting _B__call__, using setattr, etc.), but I haven't found the special trick yet. The attached script shows the example in more detail. -- >Comment By: Armin Rigo (arigo) Date: 2005-12-26 17:21 Message: Logged In: YES user_id=4771 Re-closing. This is a known documentation bug: all this is expected, but just under-documented. 'str(x)' issues a special method call to '__str__' on 'x', but the real definition of "calling a special method" on an object 'x' is as follows: look up the name "__str__" in the dict of type(x), then in the dict of the parent types in MRO order. It's really not the same thing as an attribute lookup. The reason for this, to put Michael's argument differently, is that if 'str(x)' would really work like 'x.__str__()', then this is what would occur: >>> class X(object): ...def __repr__(self): ...return "hello" ... >>> X() hello >>> X TypeError: __repr__() takes exactly 1 argument (0 given) because X.__repr__() is just an unbound method call with a missing argument. There is no such thing as "default values for self" in Python. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 20:55 Message: Logged In: YES user_id=1188172 It is not the case that the methods are unchangeable. See this example: class A(object): def __repr__(self): return 'repr' def new_repr(self): return 'new_repr' a = A() a.__repr__ = a.new_repr print a.__repr__() => prints "new_repr" print repr(a) => prints "repr" -- Comment By: Kevin Quick (kquick) Date: 2004-12-22 19:00 Message: Logged In: YES user_id=6133 Thanks for the clarifcation. However IMHO it is wrong to have different behavior for different methods. To wit, if I defined a method, it is a bound method, and ergo a "self" initial argument is automatically supplied. However, a __repr__, even though I define it, acts as an unbound method, with the self argument having a default of the current instance but overrideable if an argument is supplied on the call. This means that the argument evaluation/passing is different for these types of builtins as opposed to other methods, both of which I have defined myself. This just doesn't seem right to me, which is why I'm re-opening this bug report... sorry to be annoying, but this definitely seems inconsistent and a better explanation. My current workaround is to do the following: class foo: def __str__(self): return my_str() def my_str(self): return 'something' So that I can do "foo.my_str = lambda self: return 'something else'". When what I should be able to do is: class foo: def __str__(self): return 'something' ... foo.__str__ = lambda self: return 'something else' -- Comment By: Michael Hudson (mwh) Date: 2004-11-16 08:22 Message: Logged In: YES user_id=6656 Oh, sorry, I think I got that a bit wrong. The issue is more with bound/unbound methods -- given class O(object): def __repr__(self): ... should O.__repr__ be a bound method (O is an instance of type) or an unbound method so O.__repr__(O()) does what you expect? Python chooses the latter, but this means that you can't implement the builtin funct
[ python-Bugs-1382740 ] len() on class broken
Bugs item #1382740, was opened at 2005-12-16 20:18 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&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: Invalid Priority: 5 Submitted By: Kevin Quick (kquick) >Assigned to: Nobody/Anonymous (nobody) Summary: len() on class broken Initial Comment: With the following python input: class A: @classmethod def __len__(cls): return 12 print '1',A.__len__() print '2',A().__len__() print '3',len(A()) print '4',len(A) The output always breaks for '4' with 'TypeError: len of unsized object' Same result for @staticmethod or normal instance method declaration. -- >Comment By: Armin Rigo (arigo) Date: 2005-12-26 17:27 Message: Logged In: YES user_id=4771 Un-assigning Guido. This is a known documentation bug: all this is expected, but under-documented. Indeed, len(x) calls the special method __len__ of 'x', but that's quite different from the expression "x.__len__()". Indeed, the real definition of "calling a special method" on an object 'x' is to look up the name "__len__" in the dict of type(x), then in the dict of the parent types in MRO order. It's really not the same thing as an attribute lookup. This definition makes sense for the Python language; it has nothing to do with the C slots. The reason is more fundamental. Consider, say, what would occur if "repr(x)" was equivalent to "x.__repr__()": >>> class X(object): ...def __repr__(self): ...return "hello" ... >>> X() hello >>> X TypeError: __repr__() takes exactly 1 argument (0 given) because X.__repr__() is just an unbound method call with a missing argument. -- Comment By: Kevin Quick (kquick) Date: 2005-12-19 15:25 Message: Logged In: YES user_id=6133 This bug *may* be related to Bug#1066490 -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-12-17 04:40 Message: Logged In: YES user_id=80475 Guido, this issue arises throughout the language in various guises (for instance, it applies to __neg__ as well as __len__). It comes-up whenever built-in functions or operators bypass attribute lookup in favor of direct slot access. Much of the code in abstract.c is in the form: def PyObject_SomeFunc(o): if slots.somefunc is not None: return slots.somefunc(o) raise TypeError If we cared about this (and I'm not sure we do), the solution is to make the abstract.c functions smarter: def PyObject_SomeFunc(o): if slots.somefunc is not None: return slots.somefunc(o) try: f = gettattr(o, 'somefunc') except AttributeError: raise TypeError else: return f() The advantage of the change is restoring the symmetry between len(o) and o.__len__() where the method definition is available via attribute lookup but not via a slot. The thought is to keep the speedy access as default, but if that fails, then do a normal attribute lookup before barfing back an error message. This is precedent for this solution elsewhere in the codebase (though I don't remember where at the moment). OTOH, I'm not sure we care. pervades the code in abstract.c which is in the form: def PyObject_Size -- Comment By: Kevin Quick (kquick) Date: 2005-12-16 22:52 Message: Logged In: YES user_id=6133 That would indeed solve '4', but has a non-orthogonality of attribute propagation that I don't understand and which seems inconsistent. In my original: '1' demonstrates that __len__ is indeed in the dictionary for the class. '2' shows the expected attribute propagation effects: if at attribute is not found in the instance dictionary, the class dictionary is checked. '3' shows that len is implemented (generally) by looking for a __len__ method on the object in question. '4' confuses me, because it means that '3' isn't quite correct... With your metaclass solution (using "__metaclass__ = meta" :) it does indeed make '4' work, and '1', but '2' and '3' now do not work, showing that instance-->class propagation does not follow instance-->class-->metaclass. Or something ... Approaching this a different way: My understanding of @classmethod (or perhaps more properly @staticmethod) is that it allows "constant" methods that are independent of the particular object instance. So if I had: class C: @staticmethod def f(): return 1 then both C.f() and C().f() a
[ python-Bugs-1390605 ] time docs lack %F in strftime!
Bugs item #1390605, was opened at 2005-12-26 15:58
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390605&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: Nikos Kouremenos (nkour)
Assigned to: Nobody/Anonymous (nobody)
Summary: time docs lack %F in strftime!
Initial Comment:
time.strftime('%F', t)
'2005-12-26'
but docs hide it
they may hide more ;( :(
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-26 19:01
Message:
Logged In: YES
user_id=1188172
strftime uses the platform's C library, which happens to
support %F on your box.
As the docs explicitly tell you: "Additional directives may
be supported on certain platforms, but only the ones listed
here have a meaning standardized by ANSI C."
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390605&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1390629 ] time.strftime('%F', local_time) is okay but time.strptime no
Bugs item #1390629, was opened at 2005-12-26 16:28
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390629&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
Submitted By: Nikos Kouremenos (nkour)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime('%F', local_time) is okay but time.strptime no
Initial Comment:
THIS IS SUPER HUGE IMO
>>> a = time.strftime('%F', local_time)
>>> time.strptime(a, '%F')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/_strptime.py", line 287, in
strptime
format_regex = time_re.compile(format)
File "/usr/lib/python2.4/_strptime.py", line 264, in
compile
return re_compile(self.pattern(format), IGNORECASE)
File "/usr/lib/python2.4/_strptime.py", line 256, in
pattern
processed_format = "%s%s%s" % (processed_format,
KeyError: 'F'
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-26 19:02
Message:
Logged In: YES
user_id=1188172
Closing as Invalid, see bug #1390605.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390629&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1102649 ] pickle files should be opened in binary mode
Bugs item #1102649, was opened at 2005-01-14 22:58 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102649&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Machin (sjmachin) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: pickle files should be opened in binary mode Initial Comment: pickle (and cPickle): At _each_ mention of the pickle file, the docs should say that it should be opened with 'wb' or 'rb' mode as appropriate, so that a pickle written on one OS can be read reliably on another. The example code at the end of the section should be updated to use the 'b' flag. -- Comment By: Martin v. Löwis (loewis) Date: 2005-02-24 21:08 Message: Logged In: YES user_id=21627 sjmachin, it seems pretty clear what to do now. Would you volunteer to come up with a patch yourself? -- Comment By: John Machin (sjmachin) Date: 2005-01-19 14:51 Message: Logged In: YES user_id=480138 Re Fred's question: Refer to thread starting at http://mail.python.org/pipermail/python-dev/2003- February/033362.html Looks like the story is like this: For pickle mode 1 or higher, always use binary mode for reading/writing. For pickle mode 0, either (a) read/write in text mode and if moving to another OS, do so in text mode i.e. convert the line endings where necessary or (b) as for pickle mode 1+, stick with binary throughout. Also should add a generalisation of Tim's comment re NotePad, e.g. something like """A file written with pickle mode 0 and file mode 'wb' will contain lone linefeeds as line terminators. This will cause it to "look funny" when viewed on Windows or MacOS as a text file by editors like Notepad that do not understand this format.""" -- Comment By: Tim Peters (tim_one) Date: 2005-01-19 14:45 Message: Logged In: YES user_id=31435 Yes, binary mode should always be used, regardless of protocol. Else pickles aren't portable across boxes (in particular, Unix can't read a protocol 0 pickle produced on Windows if the latter was written to a text-mode file). "text mode" was a horrible name for protocol 0. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 06:09 Message: Logged In: YES user_id=3066 In response to irmin's comment: freopen() is only an option for real file objects; pickles are often stored or read from other sources. These other sources are usually binary to begin with, fortunately, though this issue probably deserves some real coverage in the documentation either way. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 06:06 Message: Logged In: YES user_id=3066 Is this true in all cases? Shouldn't files containing text pickles (protocol 0) be opened in text mode? (A problem, given that all protocols should be readable without prior knowledge of the protocol used to write the pickle.) -- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 16:07 Message: Logged In: YES user_id=129426 Can't the pickle code just freopen() the file itself, using binary mode? Or is this against Python's rule "explicit is better than implicit" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102649&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-649974 ] urllib.url2pathname, pathname2url doc strings inconsistent
Bugs item #649974, was opened at 2002-12-07 10:22
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Mike Brown (mike_j_brown)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.url2pathname, pathname2url doc strings inconsistent
Initial Comment:
The Unix version of urllib.url2pathname(), when given a
file URL that contains a host part, returns a path with
the host embedded in the URL, despite the fact that
there is no convention for mapping the host into the
URL. The resulting path is not usable.
For example, on Windows, there is a convention for
mapping the host part of a URL to and from a NetBIOS
name. url2pathname('//somehost/path/to/file') returns
r'\\somehost\path\to\file' which is safe to pass into open
() or os.access().
But on Unix, there is no such convention. url2pathname
('//somehost/path/to/file') returns '//somehost/path/to/file',
which means the same thing as '/somehost/path/to/file' --
somehost is just another path segment and does not
actually designate a host.
In my opinion, an exception should be raised in this
situation; url2pathname() should not try to produce an
OS path for a remote machine when there is no
convention for referencing a remote machine in that OS's
traditional path format. This way, if no exception is
raised, you know that it's safe to pass the result into
open() or os.access().
And as noted in other bug reports, 'file://localhost/' is a
special case that should be treated the same as 'file:///'.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-26 23:54
Message:
Logged In: YES
user_id=1188172
Applied patches in revisions 41816,41817.
--
Comment By: Mike Brown (mike_j_brown)
Date: 2004-12-28 06:18
Message:
Logged In: YES
user_id=371366
OK. I changed the group to Python 2.4, changed the category
to Documentation, changed the summary, and lowered the priority.
Since there are doc strings for the non-posix versions of
url2pathname() and pathname2url(), please just consider the
patches I created to be just making all of the docs
consistent among each other and consistent with the
module-level docs you pointed out.
Thanks! -Mike
--
Comment By: Facundo Batista (facundobatista)
Date: 2004-12-28 01:32
Message:
Logged In: YES
user_id=752496
The documentation for urllib states that:
Although the urllib module contains (undocumented) routines
to parse and unparse URL strings, the recommended interface
for URL manipulation is in module urlparse.
So, if you think that the files should also be modified,
change the group of this bug to 2.4. Otherwise it will be
closed as won't fix.
--
Comment By: Mike Brown (mike_j_brown)
Date: 2004-12-27 08:15
Message:
Logged In: YES
user_id=371366
See also #649961, where I propose the same solution.
--
Comment By: Mike Brown (mike_j_brown)
Date: 2004-12-27 08:04
Message:
Logged In: YES
user_id=371366
pathname2url and url2pathname are undocumented and are
urllib- and platform-specific. My complaints in this old bug
report are based on assumptions that thse functions are
general-purpose public interfaces. Upon further
investigation, I see that they are not.
I suggest leaving the implementations unchanged for now;
there are too many issues with doing it 'right' to go into
here. But perhaps add documentation that is consistent and
indicates that the functions are limited in scope. Patches
attached.
--
Comment By: Facundo Batista (facundobatista)
Date: 2004-12-26 15:52
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Facundo Batista (facundobatista)
Date: 2004-12-26 15:52
Message:
Logged In: YES
user_id=752496
Could you please provide a test case?
--
Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-12-11 07:56
Message:
Logged In: YES
user_id=250749
There i
[ python-Bugs-653542 ] PyLong_AsVoidPtr()/PyLong_FromVoidPtr()
Bugs item #653542, was opened at 2002-12-14 02:02
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653542&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: Works For Me
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyLong_AsVoidPtr()/PyLong_FromVoidPtr()
Initial Comment:
These two functions have mutually-recursive definitions
in the docs (which is to say, none).
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-26 23:59
Message:
Logged In: YES
user_id=1188172
I think the definitions are pretty clear to understand.
PyLong_FromVoidPtr makes a long from a pointer,
PyLong_AsVoidPtr makes a pointer from a long... closing as
Works for Me.
--
Comment By: Tim Peters (tim_one)
Date: 2003-09-24 03:25
Message:
Logged In: YES
user_id=31435
Nope. Guido checked them in 5 years ago, in rev 1.48. To
judge from the checkin comment, the code may actually have
come from Greg Stein. I don't have time for it, so unassigning.
--
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-24 00:00
Message:
Logged In: YES
user_id=3066
Tim, aren't these your babies?
--
Comment By: Martin v. Löwis (loewis)
Date: 2002-12-14 17:15
Message:
Logged In: YES
user_id=21627
Something very simple:
PyObject *
PyLong_FromVoidPtr(void *p)
{
#if SIZEOF_VOID_P <= SIZEOF_LONG
return PyInt_FromLong((long)p);
#else
#ifndef HAVE_LONG_LONG
# error "PyLong_FromVoidPtr: sizeof(void*) > sizeof(long),
but no long long"
#endif
#if SIZEOF_LONG_LONG < SIZEOF_VOID_P
# error "PyLong_FromVoidPtr: sizeof(LONG_LONG) < sizeof
(void*)"
#endif
/* optimize null pointers */
if (p == NULL)
return PyInt_FromLong(0);
return PyLong_FromLongLong((LONG_LONG)p);
#endif /* SIZEOF_VOID_P <= SIZEOF_LONG */
}
--
Comment By: David Abrahams (david_abrahams)
Date: 2002-12-14 15:37
Message:
Logged In: YES
user_id=52572
Thanks for asking but the problem is that I don't know what
they do!
--
Comment By: Martin v. Löwis (loewis)
Date: 2002-12-14 15:15
Message:
Logged In: YES
user_id=21627
Would you like to provide a patch?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653542&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-721160 ] Acrobat Reader 5 compatibility
Bugs item #721160, was opened at 2003-04-14 17:12 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721160&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: Acrobat Reader 5 compatibility Initial Comment: I read the comment about Adobe admitting that it can't print the Python documentation is their fault, but as the bug doesn't seem to get fixed, is there any workaround that we could make? Especially on MacOSX you have the problem that there is no Acrobat 4 that you can use (unless you want to run it under Classic), and it seems a bit silly to have all this beautiful documentation that people then can't print... -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:01 Message: Logged In: YES user_id=1188172 This has been lying around for more than two years, and the Reader is at version 7 now... I believe that I can close this as "Out of Date". -- Comment By: Thomas Heller (theller) Date: 2003-04-14 17:44 Message: Logged In: YES user_id=11105 I have been in contact with two other people about this bug, here is an extract from some conversation we had. I'll be happy to mail Fred his email adress, don't want to post it here on the web. > * From all I read, it seems that Fred Drake is convinced the problem > is an Acrobat bug, while you seem to have a good case it's actually > a problem in python.sty. At this point, contacting the Python guys Well, there is a bug in Acrobat Reader, but recent pdftex versions have a workaround for it. It might be that this is a different problem. > is appropriate - it would be great if you want to help here. Yes, I'll do this next week. > * About \url: actually I was suprized to see that urls don't work > as a link from my Acrobat (though I think I have a weblink set up > properly) - can that be related to the issue you describe? It seems python.sty defines its own \url command which apparently used to create hyperlinks, but as it was tailored to very specific pdftex (and hyperref) versions, it breaks now. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721160&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-756104 ] Calling socket.recv() with a large number breaks
Bugs item #756104, was opened at 2003-06-17 20:25 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Alex R.M. Turner (plexq) Assigned to: Nobody/Anonymous (nobody) Summary: Calling socket.recv() with a large number breaks Initial Comment: I have a backup script that calls socket.recv() passing the amount of data that is left to get for a given file as the argument. For very large files (I have one here that is 1.9Gig) it seems to break horribly after receiving about 130Meg. I have tried to track it down precisely with basic debugging (putting in print statements in the python code) but it just seams to freak out around the 130meg mark, and it just doesn't make sense. If I change the argument passed to recv to 32767 it works just fine. I have attatched the loop that reads data from the socket (In a working state, the bad code is commented out). -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:08 Message: Logged In: YES user_id=1188172 Applied your proposed wording in rev.41818/41819. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 20:07 Message: Logged In: YES user_id=752496 This is a documentation bug; something the user should be "warned" about. This caught me once, and two different persons asked about this in #python, so maybe we should put something like the following in the recv() docs. """ For best match with hardware and network realities, the value of "buffer" should be a relatively small power of 2, for example, 4096. """ If you think the wording is right, just assign the bug to me, I'll take care of it. -- Comment By: Tim Peters (tim_one) Date: 2004-09-13 16:11 Message: Logged In: YES user_id=31435 As Jeremy implied at the start, someone needs to demonstrate that "the bug" is actually in Python, not in your platform's implementation of sockets. If a C program displays the same behavior, your complaint is with your platform socket implementation. Sockets are low-level gimmicks, which is why Jeremy expected a C program to fail the same way. -- Comment By: Dmitry Dvoinikov (targeted) Date: 2004-09-13 13:17 Message: Logged In: YES user_id=1120792 I've also been hit by this problem, not at a 130Meg read, but at a mere 10Meg. Because of that I had to change my code to read many small chunks rather than a single blob and that fixed it. Still, I disagree with tim_one. If recv() is limited with the amount of data it can read per call, it should be set and documented, otherwise it is a bug and the call is unreliable. Nobody has to follow the decribed "best-practice" of reading small chunks, it actually worsens code quality, and what's worse - it makes other stuff break. Example - I was using the SimpleXMLRPCServer (Lib/SimpleXMLRPCServer.py), and it contains the following line at it's heart: data = self.rfile.read(int(self.headers["content-length"])) Guess what was happening with requests with content-length larger than 10Meg (in my case). I've aso thought the problem was with max() instead of min(), but as tim_one rightfully pointed out, this was a desired behaviour. Ironically though, replacing max() with min() fixes the problem as there is no more huge reads at lower level. -- Comment By: Tim Peters (tim_one) Date: 2004-07-27 02:41 Message: Logged In: YES user_id=31435 potterru, I don't believe plexq was using _fileobject.read() -- he said he was using socket.recv(), and all the comments later were consistent with that. The code you found does appear to *intend* max(): code following the snippet you quoted clearly expects that it may have read more than "left" bytes, and it would not be worrying about that had min() been intended. I agree the code is pretty inscrutable regardless, but we'd have to ask Guido why he wrote it that way. In any case, since this bug report is about socket.recv(), if you want to make a case that _fileobject.read() is buggy you should open a new report for that. -- Comment By: Igor E. Poteryaev (potterru) Date: 2004-07-26 13:23 Message: Logged In: YES user_id=48596 It looks like bug in module socket.py in _fileobject.read method. ... while True: left = size - buf_len recv_size =
[ python-Bugs-574241 ] Automated daily documentation builds
Bugs item #574241, was opened at 2002-06-26 21:58 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&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: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Automated daily documentation builds Initial Comment: Set-up a cron job or python script to make daily rebuilds of the Python documentation at: www.python.org/dev/doc/devel Developers using Windows and not using Cygwin do not have a method for doing their own builds. I think daily updates would be helpful for all developers and would increase the likelihood that people check their patches versus current documentation. Also, it increases the chance that someone will notice and report a documentation error earlier in the release cycle. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:10 Message: Logged In: YES user_id=1188172 This seems to have been done now, see http://docs.python.org/dev/. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 23:45 Message: Logged In: YES user_id=80475 Fred, I had thought you had made a job for this but it doesn't appear to be running on a regular basis. -- Comment By: Michael Hudson (mwh) Date: 2004-08-19 16:49 Message: Logged In: YES user_id=6656 I'd have thought it was an entirely reasonable use of the starship, but I guess you could ask on the crew list first if you want to be really polite... -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-19 08:39 Message: Logged In: YES user_id=3066 Perhaps that's good enough, though I've generally done updates from the latest CVS. Would anyone object to my setting up a cronjob to perform the build on starship? It appears that sufficient software is installed on that machine to perform the build (and much faster than on anything I have). -- Comment By: Martin v. Löwis (loewis) Date: 2004-08-19 08:03 Message: Logged In: YES user_id=21627 For a daily build, it is IMO sufficient to use the anonymous CVS - it may be a few hours behind, but you'ld have to wait a full day anyway for the changes to show up. If somebody builds the documentation elsewhere, a cronjob on python.org could pick it up from "elsewhere", which would mean no access to python.org is necessary. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-19 05:18 Message: Logged In: YES user_id=3066 At this point it is trivial to checkout and build the documentation automatically, with one caveat. The script would need to be able to do an authenticated checkout from SourceForge, and needs to be able to log into the python.org webserver as one of the webmasters to install the fresh tarball. While an anonymous checkout of the documentation sources is possible, it's out of date by several hours (as long as we use SF's CVS). That means the script needs to run within the context of an ssh-agent with the right keys added, or the keys must not have passphrases. I'm too paranoid to live without passphrases on my private keys, and I really haven't thought about how to run a cron job such that it can use a properly populated ssh-agent, but that seems conceptually fragile. (Who *always* has such an agent running, not just when logged in directly?) The documentation build is too heavy a process to run on the python.org webserver itself, and that still relies on being able to do an authenticated checkout from SF. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-17 04:36 Message: Logged In: YES user_id=80475 With your new automation scripts is it now possible to run a daily cron job? -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-02 21:03 Message: Logged In: YES user_id=3066 I don't think failing frequently is a problem if the failure shows up in someone's email. It should probably go to [EMAIL PROTECTED], and I can turn that into a fix. Perhaps it should go to the Doc-SIG instead, to allow more people to help. -- Comment By: Martin v. Löwis (loewis) Date: 2002-06-30 20:46 Message: Logg
[ python-Bugs-839585 ] String formatting operator % badly documented
Bugs item #839585, was opened at 2003-11-10 23:11 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839585&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert Siemer (siemer) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: String formatting operator % badly documented Initial Comment: Hello everyone! The % operator works with strings, but this is hard to find in the documentation (Library Reference 2.2.6.2). Really bad is, that an operator should be documented in the Language Reference, where it isn't. Lang-Ref "5.6 Binary arithmetic operations" is labeled wrong, as it also describes the non-arithmetic operations of + and * but seems to know nothing about % under that aspect... It is actually indirectly saying that there is no further non-arithmetic operation - but there is: %. Rob -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:16 Message: Logged In: YES user_id=1188172 Applied corrected patch in rev. 41820/41821. -- Comment By: Michael Chermside (mcherm) Date: 2004-03-20 20:00 Message: Logged In: YES user_id=99874 Two thoughts I had after attaching that patch. (1) If there's a way to create inter-document links, that would be a good idea. I don't know of one. (2) If the format of this patch is a pain, let me know. All I'm doing is adding one paragraph. -- Comment By: Michael Chermside (mcherm) Date: 2004-03-20 19:52 Message: Logged In: YES user_id=99874 Good point, this has long bothered me too. I'm attaching a patch. Fred, can you review (make sure I didn't introduce broken tex syntax) and check in? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839585&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-839075 ] Document that highly recursive data cannot be pickled
Bugs item #839075, was opened at 2003-11-10 08:21
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839075&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: Simon David Burton (simonb1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Document that highly recursive data cannot be pickled
Initial Comment:
Make a note in section 3.4.14 Python Library Reference
(perhaps a footnote?) that higly recursive data
stuctures cannot be pickled. Setting the stack limit
helps a bit, but does not scale to large networks of data.
eg.
#!/usr/bin/env python
import cPickle as pickle
#import pickle
import os
#sys.setrecursionlimit(4000)
N = 2048
print "building..."
nest = [ [] for i in range(N) ]
for i in range(N):
for j in range(N):
nest[i].append( nest[j] )
print "dumping..."
file = open("nest.pkl","wb")
try:
pickle.dump( nest, file )
except RuntimeError, e:
print e
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-27 00:28
Message:
Logged In: YES
user_id=1188172
Added a note to the docs in rev. 41822/41823.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839075&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-845342 ] os.exec* and first 'arg'
Bugs item #845342, was opened at 2003-11-19 20:30 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845342&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: Wont Fix Priority: 5 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Nobody/Anonymous (nobody) Summary: os.exec* and first 'arg' Initial Comment: The current I'd suggest the following change to the docstrings for the exec* functions, because I think it's quite easy to get bitten: execv(...) execv(path, args) Execute an executable path with arguments, replacing current process. path: path of executable file args: tuple or list of strings (NOTE: the first argument is analoguous to sys.argv[0], *not* sys.argv[1]!) instead of: execv(...) execv(path, args) Execute an executable path with arguments, replacing current process. path: path of executable file args: tuple or list of strings -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:31 Message: Logged In: YES user_id=1188172 This is covered in the Library Manual. Docstrings aren't meant to be complete, just quick overviews of what the functions do. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845342&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-954981 ] Error in urllib2 Examples
Bugs item #954981, was opened at 2004-05-16 23:33
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=954981&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: Phillip (phillip_)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in urllib2 Examples
Initial Comment:
I'll quote from the urllib2 examples:
>>>
Here we are sending a data-stream to the stdin of a CGI
and reading the data it returns to us:
>>> import urllib2
>>> req =
urllib2.Request(url='https://localhost/cgi-bin/test.cgi',
... data='This data is passed to
stdin of the CGI')
>>> f = urllib2.urlopen(req)
...
<<<
urllib2 returns:
urllib2.URLError:
(This is the Errormsg in 2.3.3, 2.2.3 is a different
syntax but says the same. This is seriously misleading,
as it implies that somehow urllib2 can handle https,
which it can't in this manner. At least not in the way
exampled here.
Please correct or delete this example.
It would be nice if you could provide a working example
for handling https. Examples are a good thing in the
whole httplib / urllib / urllib2 area, since it appears
somewhat hard to overlook.
I'm sorry I can't provide a working version of this
example, as I am trying to figure out how to handle
https myself.
Anyway, it's a documentation bug and needs fixing.
Thanks.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-27 00:37
Message:
Logged In: YES
user_id=1188172
Added the note Martin suggested in rev. 41824/41825.
--
Comment By: Martin v. Löwis (loewis)
Date: 2004-06-03 11:38
Message:
Logged In: YES
user_id=21627
What operating system are you using? The example works fine
for me, when modified to use an actual web server:
>>>
urllib2.Request("https://sourceforge.net/tracker/index.php","func=detail&aid=954981&group_id=5470&atid=105470";)
>>>
r=urllib2.Request("https://sourceforge.net/tracker/index.php","func=detail&aid=954981&group_id=5470&atid=105470";)
>>> f=urllib2.urlopen(r)
>>> f.read()
Can you provide the complete traceback?
For https to work, your Python installation must support
SSL. For this, import _ssl must succeed. For that to work,
OpenSSL must have been used when Python was built.
I can add a text to the documentation indicating that the
example fails if the Python installation does not support SSL.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=954981&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-489256 ] Lib/profile.doc should be updated
Bugs item #489256, was opened at 2001-12-05 06:51 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&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: Anthony Baxter (anthonybaxter) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: Lib/profile.doc should be updated Initial Comment: What's Lib/profile.doc doing there? Is it still needed? Why is it in Lib, anyway? (it seems very old - is it still up to date after all the hackery? doesn't seem so) -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:44 Message: Logged In: YES user_id=1188172 Commented out the notes about the old profiler in rev. 41826. Closing this bug now. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-10 10:07 Message: Logged In: YES user_id=469548 I just checked and there was no information in profile.doc that wasn't in the library reference, so I've removed it now. I've also replaced help() along the lines of what you suggested. Just one more question: could we remove the "How Is This Profiler Different From The Old Profiler?" subsection from the library reference? It's hardly relevant, considering that the Old Profiler was last seen in Python 1.1 (!). -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-10 04:07 Message: Logged In: YES user_id=3066 Removing profile.doc sounds fine to me. The only thing that really needs to be done prior to removal is to make sure all the (still current) information in profile.doc is represented in the library documentation. The help() function should probably be replaced with something that refers the user to the library documentation, rather than removing the function. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 02:27 Message: Logged In: YES user_id=469548 I would like to go ahead with removing profile.doc and the help() function from profile.py for Python 2.5. They're not really all that helpful, they're in an unexpected place, and they're undocumented. I'll remove them if there are no objections within some weeks. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 07:08 Message: Logged In: YES user_id=3066 profile.doc is used as the help file for profile.py, and is read by an external pager (sloppily) using the profile.help() function. Either the document should be updated and the help() function should be more intelligent about the pager, or... ...the document and the help() function should be removed. This is a possibility since help() is not documented. profile.doc should be updated for Python 2.2; other changes will need to wait for Python 2.3. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-922690 ] package manager page outdated link
Bugs item #922690, was opened at 2004-03-24 21:07 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922690&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Jack Jansen (jackjansen) Summary: package manager page outdated link Initial Comment: The page http://www.python.org/packman/ has outdated links to Bob Ippolito's page. The correct link appears to be http://undefined.org/python/ (which includes links to various versions of the packages and to descriptions of the same). -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:52 Message: Logged In: YES user_id=1188172 This is still a problem. The packman page needs update, as it seems. -- Comment By: Terry J. Reedy (tjreedy) Date: 2004-03-30 18:57 Message: Logged In: YES user_id=593130 To supplement the summary: the two links (xml and html) on the bottom of the packman page work but they are specific to (an older? verseion) the pimp package. The higher link suggested as a substitue lists other packages, including some that appear to have been extracted from pimp. Since the current page references aeve 0.0.3 while the suggested link references aeve 0.0.4, the suggest change seems proper. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922690&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1389673 ] Incorrect docs for return values of set update methods
Bugs item #1389673, was opened at 2005-12-24 19:27 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389673&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: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect docs for return values of set update methods Initial Comment: The documentation for set.update(), set.intersection_update(), set.difference_update() and set.symmetric_difference_update currently (as of r41806) states that these methods all return the updated set, implying that this is a not-in-place change. In fact, these methods do operate in place, each one of them returning None. The attached diff (against Doc/lib/libstdtypes.tex, r41806) fixes this, making it clear that these are in-place operations. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:56 Message: Logged In: YES user_id=1188172 Thanks, applied the patch in rev. 41827/41828. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389673&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1385004 ] exec statement link in index broken
Bugs item #1385004, was opened at 2005-12-19 10:05 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385004&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Harri Pasanen (harripasanen) Assigned to: Nobody/Anonymous (nobody) Summary: exec statement link in index broken Initial Comment: In library reference index: http://www.python.org/doc/2.4.2/lib/genindex.html "exec statement" points to http://www.python.org/doc/2.4.2/lib/bltin-code-objects.html#l2h-265 Which seems wrong. (2.4 docs already had the same). -Harri -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 01:00 Message: Logged In: YES user_id=1188172 That's correct in a sense because the exec statement isn't described in the Library Manual. The index entry links to "Code Objects" because exec is mentioned there. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385004&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1386675 ] _winreg specifies EnvironmentError instead of WindowsError
Bugs item #1386675, was opened at 2005-12-21 02:41 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: _winreg specifies EnvironmentError instead of WindowsError Initial Comment: The _winreg documentation says that EnvironmentError will be raised (throughout the docs, for various reasons), when, in every case, WindowsError is actually raised. A simple replace of WindowsError for EnvironmentError would fix this. (Let me know if you really need a patch). -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 01:03 Message: Logged In: YES user_id=1188172 Corrected in rev. 41829/41830. -- Comment By: Tony Meyer (anadelonbrin) Date: 2005-12-26 03:36 Message: Logged In: YES user_id=552329 I don't see what purpose there is in having the documentation say that EnvironmentError is raised, when a subclass is. _winreg is still marked as a temporary module to be replaced, so it's hard to believe it's some sort of future-proofing. One could say that Exception is raised, since EnvironmentError is a subclass of Exception, but explicit is better than implicit, right? (import _winreg fails on non-Windows platforms, so I don't see how it could be for cross-platform reasons, either). -- Comment By: Fredrik Lundh (effbot) Date: 2005-12-25 12:44 Message: Logged In: YES user_id=38376 however, note that >>> issubclass(WindowsError, EnvironmentError) True on windows, and >>> issubclass(WindowsError, EnvironmentError) Traceback (most recent call last): File "", line 1, in NameError: name 'WindowsError' is not defined on non-windows platforms, so it might be done this way on purpose. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1375599 ] Tutorial errors
Bugs item #1375599, was opened at 2005-12-07 19:55 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1375599&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: Glen Kaukola (gkaukola) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial errors Initial Comment: In section 1 of the tutorial, it says this: "Python enables programs to written compactly and readably." It should probably read like so: "Python enables programs to be written compactly and readably." I'd like it even better like so: "Python enables programs to be compact and readable." Also, even though it probably doesn't matter really since it's just an example, in your Fibonacci sequence example in section 4.6 it should probably be "while b <= n" as opposed to "while b < n". Because if n == 1, nothing is spit out. But even then it still wouldn't handle 0. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 01:06 Message: Logged In: YES user_id=1188172 Corrected the 2.4 branch version in rev. 41831. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-08 07:05 Message: Logged In: YES user_id=33168 Not sure where you are seeing the grammar problem in section 1. It is fixed in SVN and on this page: http://docs.python.org/tut/tut.html Presumably you are looking at an old version. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1375599&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1152424 ] Dict docstring error Python-2.3.5
Bugs item #1152424, was opened at 2005-02-26 17:19 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152424&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: Works For Me Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: Dict docstring error Python-2.3.5 Initial Comment: Minor error, epydoc reports the following: === In __builtin__.dict docstring: --- L3: Error: Improper paragraph indentation. L5: Error: Improper paragraph indentation. L7: Error: Improper paragraph indentation. L9: Error: Improper paragraph indentation. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 01:10 Message: Logged In: YES user_id=1188172 I can't find anything wrong with that docstring. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152424&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1390991 ] lambda functions confused when mapped in dictionary object
Bugs item #1390991, was opened at 2005-12-27 03:00
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=1390991&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: Open
Resolution: None
Priority: 5
Submitted By: Samuel Hsiung (shsiung)
Assigned to: Nobody/Anonymous (nobody)
Summary: lambda functions confused when mapped in dictionary object
Initial Comment:
***Background***
Lambda functions wrapped around different module
functions overwrite each other when mapped one at a
time in a dictionary object.
Python Version: 2.4.2
***Duplication Instructions***
1. Setup
===module foo.py===
def callme(x):
print "foo called!"
print x
===module bar.py===
def callme(x):
print "bar called!"
print x
===module call.py===
import foo, bar
api = {}
modules = (foo, bar)
for module in modules:
api[module] = lambda x: module.callme(x)
print '%s mapped to %s' % (module, api[module])
api[foo]('above line should be foo')
api[bar]('above line should be bar')
print "foo lambda: %s" % api[foo]
print "bar lambda: %s" % api[bar]
2. Execution
=> python call.py
mapped to at 0xb7f7abc4>
mapped to at 0xb7f7abfc>
bar called!
above line should be foo
bar called!
above line should be bar
foo lambda: at 0xb7f7abc4>
bar lambda: at 0xb7f7abfc>
3. Expected behaviour
foo should have been called, followed by bar; instead
bar was called twice.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390991&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1152424 ] Dict docstring error Python-2.3.5
Bugs item #1152424, was opened at 2005-02-26 11:19 Message generated for change (Comment added) made by cjwhrh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152424&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: Works For Me Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: Dict docstring error Python-2.3.5 Initial Comment: Minor error, epydoc reports the following: === In __builtin__.dict docstring: --- L3: Error: Improper paragraph indentation. L5: Error: Improper paragraph indentation. L7: Error: Improper paragraph indentation. L9: Error: Improper paragraph indentation. -- >Comment By: Colin J. Williams (cjwhrh) Date: 2005-12-26 22:52 Message: Logged In: YES user_id=285587 This was not an important problem ten months ago but I suggest that the reported problem needs attention - I no longer have 2.3 installed. Assuming for a moment that there is no problem with the doc string then there was a problem with the epydoc/python combination. Shouldn't the problem have been passed on the the epydoc people? Colin W. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-26 19:10 Message: Logged In: YES user_id=1188172 I can't find anything wrong with that docstring. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152424&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
