[ python-Bugs-1703448 ] "t.join(); assert t not in threading.enumerate()" fails
Bugs item #1703448, was opened at 2007-04-19 18:22
Message generated for change (Comment added) made by spiv
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703448&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andrew Bennetts (spiv)
Assigned to: Raymond Hettinger (rhettinger)
Summary: "t.join(); assert t not in threading.enumerate()" fails
Initial Comment:
This script always fails for me, usually on the very first iteration:
import threading
while True:
print '.',
t = threading.Thread(target=lambda: None)
t.start()
t.join()
alive_threads = threading.enumerate()
assert len(alive_threads) == 1, alive_threads
The docs clearly say this is expected to work: Thread.join is described as
"Wait until the thread terminates" and threading.enumerate's description says
it will "Return a list of all currently active Thread objects ... It excludes
terminated threads". So by the time t.join() returns, the thread should not be
reported by threading.enumerate anymore.
The bug appears to be that while the thread is shutting down, join() may exit
too early: it waits for the __stopped flag to be set, but the thread hasn't
necessarily been removed from the _active dict by that time, so enumerate will
report a "stopped" thread. (Or if you like the bug is that __stopped is can be
set while the thread is still in the _active dict.)
A workaround is to filter the results of threading.enumerate() through [t for t
in threading.enumerate() if t.isAlive()].
--
>Comment By: Andrew Bennetts (spiv)
Date: 2007-04-23 17:03
Message:
Logged In: YES
user_id=50945
Originator: YES
gagenellina: thanks for taking a look!
For what it's worth, I can reproduce this with that script using the
Python 2.4 and 2.5 that come with Ubuntu 7.04 ("Feisty Fawn"), on an i386
laptop, so hopefully other people on a similar platform can also reproduce
this.
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-04-23 15:51
Message:
Logged In: YES
user_id=479790
Originator: NO
The analysis appears to be correct, but I can't reproduce the bug with 2.5
on Windows XP SP2.
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-04-23 15:21
Message:
Logged In: YES
user_id=479790
Originator: NO
The analysis appears to be correct, but I can't reproduce the bug with 2.5
on Windows XP SP2.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703448&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1705362 ] cannot change cursor color in IDLE
Bugs item #1705362, was opened at 2007-04-22 19:14 Message generated for change (Comment added) made by zorkin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705362&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 Private: No Submitted By: zorkin (zorkin) Assigned to: Nobody/Anonymous (nobody) Summary: cannot change cursor color in IDLE Initial Comment: Python 2.5.1 for windows When I change the cursor color to another color, it still stays black, so I can't really make black background. -- >Comment By: zorkin (zorkin) Date: 2007-04-23 07:33 Message: Logged In: YES user_id=1741501 Originator: YES The page on the link says you can invert it. As I understand, the caret color is either black or background color. You could force it to be black/white. Also you should hide this option in selector - it's misleading, because I thought i does something. -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-04-23 05:48 Message: Logged In: YES user_id=479790 Originator: NO IDLE on Windows appears to be using an always-black caret (cursor) - not the standard caret behavior, which does its "blinking" by inverting the background color. So something might be improved here, but I doubt you can reliably set the caret color on Windows; see http://support.microsoft.com/kb/84054/en-us -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705362&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1705717 ] Error in sys.argv documenation
Bugs item #1705717, was opened at 2007-04-23 02:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kamil Kisiel (kisielk) Assigned to: Nobody/Anonymous (nobody) Summary: Error in sys.argv documenation Initial Comment: >From the current version on http://docs.python.org/lib/module-sys.html: argv The list of command line arguments passed to a Python script. argv[0] is the script name (it is operating system dependent whether this is a full pathname or not). If the command was executed using the -c command line option to the interpreter, argv[0] is set to the string '-c'. If no script name was passed to the Python interpreter, argv has zero length. The last line, "If no script name was passed to the Python interpreter, argv has zero length." does not appear to be correct, the length of argv is 1 and argv[0] is '': [EMAIL PROTECTED]:~$ python2.5 Python 2.5 (release25-maint, Dec 9 2006, 14:35:53) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> len(sys.argv) 1 >>> sys.argv[0] '' >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705717&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1705365 ] 'nonlocal x' at top level crashes interpreter
Bugs item #1705365, was opened at 2007-04-23 05:20
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705365&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 3000
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: John Reese (johnreese)
Assigned to: Nick Coghlan (ncoghlan)
Summary: 'nonlocal x' at top level crashes interpreter
Initial Comment:
A nonlocal declaration at the interpreter top level causes a bus error. This
happens in the p3yk branch at head (r54922). Reporter is using MacOS 10.4.9 on
Intel. Reporter is perfectly aware that nonlocal doesn't do anything useful at
the top level, but feels it should not crash the interpreter.
% gdb python3.0
GNU gdb 6.3.50-20050815 (Apple version gdb-563) (Wed Jul 19 05:10:58 GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for shared
libraries .. done
(gdb) run
Starting program: /Users/jtr/bin/python3.0
Reading symbols for shared libraries . done
Python 3.0x (p3yk:54922, Apr 22 2007, 12:15:19)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> nonlocal x
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0004
PySet_Contains (anyset=0x0, key=0x532640) at Objects/setobject.c:2129
2129if (!PyAnySet_Check(anyset)) {
(gdb) The program is running. Exit anyway? (y or n) y
--
>Comment By: Nick Coghlan (ncoghlan)
Date: 2007-04-23 20:18
Message:
Logged In: YES
user_id=1038590
Originator: NO
Fixed in rev 54925 to raise SyntaxError instead of crashing.
The bug appears to have been present in the original nonlocal code - both
the original code and the refactored code checked if a nonlocal variable
was in the set of bound names without first checking that the relevant
pointer was non-NULL.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-04-23 08:23
Message:
Logged In: YES
user_id=849994
Originator: NO
Nick, that crash is in the symtable code you refactored with the setcomp
patch.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705365&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1701389 ] utf-16 codec problems with multiple file append
Bugs item #1701389, was opened at 2007-04-16 12:05
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1701389&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: Unicode
Group: Python 2.5
Status: Closed
Resolution: Remind
Priority: 5
Private: No
Submitted By: Iceberg Luo (iceberg4ever)
Assigned to: M.-A. Lemburg (lemburg)
Summary: utf-16 codec problems with multiple file append
Initial Comment:
This bug is similar but not exactly the same as bug215974.
(http://sourceforge.net/tracker/?group_id=5470&atid=105470&aid=215974&func=detail)
In my test, even multiple write() within an open()~close() lifespan will not
cause the multi BOM phenomena mentioned in bug215974. Maybe it is because bug
215974 was somehow fixed during the past 7 years, although Lemburg classified
it as WontFix.
However, if a file is appended for more than once, by an
"codecs.open('file.txt', 'a', 'utf16')", the multi BOM appears.
At the same time, the saying of "(Extra unnecessary) BOM marks are removed from
the input stream by the Python UTF-16 codec" in bug215974 is not true even in
today, on Python2.4.4 and Python2.5.1c1 on Windows XP.
Iceberg
--
PS: Did not find the "File Upload" checkbox mentioned in this web page, so I
think I'd better paste the code right here...
import codecs, os
filename = "test.utf-16"
if os.path.exists(filename): os.unlink(filename) # reset
def myOpen():
return codecs.open(filename, "a", 'UTF-16')
def readThemBack():
return list( codecs.open(filename, "r", 'UTF-16') )
def clumsyPatch(raw): # you can read it after your first run of this program
for line in raw:
if line[0] in (u'\ufffe', u'\ufeff'): # get rid of the BOMs
yield line[1:]
else:
yield line
fout = myOpen()
fout.write(u"ab\n") # to simplify the problem, I only use ASCII chars here
fout.write(u"cd\n")
fout.close()
print readThemBack()
assert readThemBack() == [ u'ab\n', u'cd\n' ]
assert os.stat(filename).st_size == 14 # Only one BOM in the file
fout = myOpen()
fout.write(u"ef\n")
fout.write(u"gh\n")
fout.close()
print readThemBack()
#print list( clumsyPatch( readThemBack() ) ) # later you can enable this fix
assert readThemBack() == [ u'ab\n', u'cd\n', u'ef\n', u'gh\n' ] # fails here
assert os.stat(filename).st_size == 26 # not to mention here: multi BOM appears
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2007-04-23 12:56
Message:
Logged In: YES
user_id=89016
Originator: NO
But BOMs *may* appear in normal content: Then their meaning is that of
ZERO WIDTH NO-BREAK SPACE (see
http://docs.python.org/lib/encodings-overview.html for more info).
--
Comment By: Iceberg Luo (iceberg4ever)
Date: 2007-04-20 05:39
Message:
Logged In: YES
user_id=1770538
Originator: YES
If such a bug would be fixed, either StreamWriter or StreamReader should
do something.
I can understand Doerwalter that it is somewhat not comfortable for a
StreamWriter to detect whether these is already a BOM at current file
header, especially when operating in append mode. But, IMHO, the
StreamReader should be able to detect multi BOM during its life span and
automatically ignore the non-first one, providing that a BOM is never
supposed to occur in normal content. Not to mention that such a Reader
seems exist for a while, according to the "(extra unnecessary) BOM marks
are removed
from the input stream by the Python UTF-16 codec" in bug215974
(http://sourceforge.net/tracker/?group_id=5470&atid=105470&aid=215974&func=
detail).
Therefore I don't think a WontFix will be the proper FINAL solution for
this case.
--
Comment By: Walter Dörwald (doerwalter)
Date: 2007-04-19 13:30
Message:
Logged In: YES
user_id=89016
Originator: NO
Closing as "won't fix"
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2007-04-19 12:35
Message:
Logged In: YES
user_id=38388
Originator: NO
I suggest you close this as wont fix.
--
Comment By: Walter Dörwald (doerwalter)
Date: 2007-04-19 12:30
Message:
Logged In: YES
user_id=89016
Originator: NO
append mode is simply not supported for codecs. How would the codec find
out the codec state that was active after the last characters where written
to the file?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1701389&group_id=5470
___
Python-bugs-list mailing
[ python-Bugs-1697248 ] Property with -> annotation triggers assert
Bugs item #1697248, was opened at 2007-04-10 09:05 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697248&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 3000 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Property with -> annotation triggers assert Initial Comment: Example: # x.py class C: @property def p(self) -> int: return 0 $ ./python -E x.py python: ../Python/ast.c:724: ast_for_arguments: Assertion `((n)->n_type) == 263 || ((n)->n_type) == 267' failed. Aborted $ Removing "@property" or "-> int" from the example avoids the problem. Adding argument annotations inside the argument list doesn't trigger it. -- >Comment By: Nick Coghlan (ncoghlan) Date: 2007-04-23 21:06 Message: Logged In: YES user_id=1038590 Originator: NO Fixed in rev 54926 (the check for whether or not decorators were present wasn't quite right). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697248&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1705365 ] 'nonlocal x' at top level crashes interpreter
Bugs item #1705365, was opened at 2007-04-23 05:20
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705365&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 3000
>Status: Closed
>Resolution: Fixed
Priority: 6
Private: No
Submitted By: John Reese (johnreese)
Assigned to: Nick Coghlan (ncoghlan)
Summary: 'nonlocal x' at top level crashes interpreter
Initial Comment:
A nonlocal declaration at the interpreter top level causes a bus error. This
happens in the p3yk branch at head (r54922). Reporter is using MacOS 10.4.9 on
Intel. Reporter is perfectly aware that nonlocal doesn't do anything useful at
the top level, but feels it should not crash the interpreter.
% gdb python3.0
GNU gdb 6.3.50-20050815 (Apple version gdb-563) (Wed Jul 19 05:10:58 GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for shared
libraries .. done
(gdb) run
Starting program: /Users/jtr/bin/python3.0
Reading symbols for shared libraries . done
Python 3.0x (p3yk:54922, Apr 22 2007, 12:15:19)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> nonlocal x
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0004
PySet_Contains (anyset=0x0, key=0x532640) at Objects/setobject.c:2129
2129if (!PyAnySet_Check(anyset)) {
(gdb) The program is running. Exit anyway? (y or n) y
--
>Comment By: Nick Coghlan (ncoghlan)
Date: 2007-04-23 21:07
Message:
Logged In: YES
user_id=1038590
Originator: NO
Fixed in rev 54925 to raise SyntaxError instead of crashing.
The bug appears to have been present in the original nonlocal code - both
the original code and the refactored code checked if a nonlocal variable
was in the set of bound names without first checking that the relevant
pointer was non-NULL.
--
Comment By: Nick Coghlan (ncoghlan)
Date: 2007-04-23 20:18
Message:
Logged In: YES
user_id=1038590
Originator: NO
Fixed in rev 54925 to raise SyntaxError instead of crashing.
The bug appears to have been present in the original nonlocal code - both
the original code and the refactored code checked if a nonlocal variable
was in the set of bound names without first checking that the relevant
pointer was non-NULL.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-04-23 08:23
Message:
Logged In: YES
user_id=849994
Originator: NO
Nick, that crash is in the symtable code you refactored with the setcomp
patch.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705365&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1705997 ] pydoc.py has typo.
Bugs item #1705997, was opened at 2007-04-23 11: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=1705997&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: charlesmchen (charlesmchen) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc.py has typo. Initial Comment: pydoc.py has typo. file: C:\Python25\Lib\pydoc.py method: locate quote: def locate(path, forceload=0): """Locate an object by name or dotted path, importing as necessary.""" parts = [part for part in split(path, '.') if part] module, n = None, 0 while n < len(parts): nextmodule = safeimport(join(parts[:n+1], '.'), forceload) if nextmodule: module, n = nextmodule, n + 1 else: break if module: object = module for part in parts[n:]: try: object = getattr(object, part) except AttributeError: return None return object else: if hasattr(__builtin__, path): return getattr(__builtin__, path) bug: I believe that by '__builtin__' you meant '__builtins__' in the last two lines. if hasattr(__builtin__, path): return getattr(__builtin__, path) should read: if hasattr(__builtins__, path): return getattr(__builtins__, path) >>> sys.platform 'win32' >>> sys.version '2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]' Thanks, Charles -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705997&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-1706256 ] Give Partial the ability to skip positionals
Feature Requests item #1706256, was opened at 2007-04-23 20:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&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
Private: No
Submitted By: Calvin Spealman (ironfroggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Give Partial the ability to skip positionals
Initial Comment:
There are some situations where you want to skip positional arguments in a use
of a partial function. In other words, you want to create a partial that
applies positional arguments out of order or without applying values to one or
more lower positional arguments. In some cases keyword arguments can be used
instead, but this has two obvious drawbacks. Firstly, it causes the caller to
rely on the name of a positional in a callee, which breaks encapsulation.
Secondly, on the case of the function being applied to being a builtin, it
fails completely, as they will not take positional arguments by name at all. I
propose a class attribute to the partial type, 'skip', which will be a
singleton to pass to a partial object signifying this skipping of positionals.
The following example demonstrates.
from functools import partial
def add(a, b):
return a + b
append_abc = partial(add, partial.skip, "abc")
assert append_abc("xyz") == "xyzabc"
Obviously this example would break if used as partial(add, b="abc") and the
maintainer of add changed the positional names to 'first' and 'second' or 'pre'
and 'post', which is perfectly reasonable. We do not need to expect the names
of our positional arguments are depended upon. It would also break when someone
gets smart and replaces the add function with operator.add, of course.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&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-1706256 ] Give Partial the ability to skip positionals
Feature Requests item #1706256, was opened at 2007-04-23 20:18
Message generated for change (Comment added) made by ironfroggy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&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
Private: No
Submitted By: Calvin Spealman (ironfroggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Give Partial the ability to skip positionals
Initial Comment:
There are some situations where you want to skip positional arguments in a use
of a partial function. In other words, you want to create a partial that
applies positional arguments out of order or without applying values to one or
more lower positional arguments. In some cases keyword arguments can be used
instead, but this has two obvious drawbacks. Firstly, it causes the caller to
rely on the name of a positional in a callee, which breaks encapsulation.
Secondly, on the case of the function being applied to being a builtin, it
fails completely, as they will not take positional arguments by name at all. I
propose a class attribute to the partial type, 'skip', which will be a
singleton to pass to a partial object signifying this skipping of positionals.
The following example demonstrates.
from functools import partial
def add(a, b):
return a + b
append_abc = partial(add, partial.skip, "abc")
assert append_abc("xyz") == "xyzabc"
Obviously this example would break if used as partial(add, b="abc") and the
maintainer of add changed the positional names to 'first' and 'second' or 'pre'
and 'post', which is perfectly reasonable. We do not need to expect the names
of our positional arguments are depended upon. It would also break when someone
gets smart and replaces the add function with operator.add, of course.
--
>Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-23 23:45
Message:
Logged In: YES
user_id=112166
Originator: YES
File Added: partial_skip.patch
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1703110 ] Incorrect example for add_password()
Bugs item #1703110, was opened at 2007-04-18 09:56
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703110&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: Accepted
Priority: 5
Private: No
Submitted By: Bob Kline (bkline)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Incorrect example for add_password()
Initial Comment:
In the documentation for urllib2, the example [1] for using basic HTTP
authentication has the following code for the call to add_password():
auth_handler.add_password('realm', 'host', 'username', 'password')
This actually worked in earlier (pre-2.4.3) versions of urllib2, but even in
those older versions, the documentation for HTTPPasswordMgr.add_password()
makes it clear that a URI must be passed as the second argument to the method,
not a host name.
Even though the behavior in the library method has changed (passing a full URI
versions of Python earlier than 2.4.3 didn't work, at least when a non-standard
port was specified), the documentation has not changed (the add_password()
documentation specifies a URI, even in the pre-2.4.3 versions of Python) and
the examples in the documentation for urllib2 still say 'host'.
[1] http://docs.python.org/lib/urllib2-examples.html
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-23 21:54
Message:
Logged In: YES
user_id=33168
Originator: NO
Thanks for the patch!
Committed revision 54932.
Committed revision 54933. (2.5)
--
Comment By: Bob Kline (bkline)
Date: 2007-04-22 18:38
Message:
Logged In: YES
user_id=291529
Originator: YES
File Added: bug1703110.patch
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-04-22 15:25
Message:
Logged In: YES
user_id=849994
Originator: NO
The docs are maintained separately, you'll have to look at
Doc/lib/liburllib2.tex.
--
Comment By: Bob Kline (bkline)
Date: 2007-04-22 14:00
Message:
Logged In: YES
user_id=291529
Originator: YES
If I'm not right in assuming that the documentation is generated directly
from urllib2.py let me know and I'll try to find the right separate file in
svn.
File Added: urllib2.py.patch
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-21 16:49
Message:
Logged In: YES
user_id=33168
Originator: NO
Bob, can you submit a patch to correct these problems? Note: we no
longer support the 2.4 series.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703110&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-1706256 ] Give Partial the ability to skip positionals
Feature Requests item #1706256, was opened at 2007-04-24 02:18
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&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
Private: No
Submitted By: Calvin Spealman (ironfroggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Give Partial the ability to skip positionals
Initial Comment:
There are some situations where you want to skip positional arguments in a use
of a partial function. In other words, you want to create a partial that
applies positional arguments out of order or without applying values to one or
more lower positional arguments. In some cases keyword arguments can be used
instead, but this has two obvious drawbacks. Firstly, it causes the caller to
rely on the name of a positional in a callee, which breaks encapsulation.
Secondly, on the case of the function being applied to being a builtin, it
fails completely, as they will not take positional arguments by name at all. I
propose a class attribute to the partial type, 'skip', which will be a
singleton to pass to a partial object signifying this skipping of positionals.
The following example demonstrates.
from functools import partial
def add(a, b):
return a + b
append_abc = partial(add, partial.skip, "abc")
assert append_abc("xyz") == "xyzabc"
Obviously this example would break if used as partial(add, b="abc") and the
maintainer of add changed the positional names to 'first' and 'second' or 'pre'
and 'post', which is perfectly reasonable. We do not need to expect the names
of our positional arguments are depended upon. It would also break when someone
gets smart and replaces the add function with operator.add, of course.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-04-24 07:41
Message:
Logged In: YES
user_id=21627
Originator: NO
I would not call it partial.skip, but partial.unbound (or find yet a
better name that indicates that the argument is not skipped, but instead
will be an argument of the resulting partial function).
--
Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-24 05:45
Message:
Logged In: YES
user_id=112166
Originator: YES
File Added: partial_skip.patch
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
