From report at bugs.python.org Sat Nov 1 15:59:31 2008
From: report at bugs.python.org (robwolfe)
Date: Sat, 01 Nov 2008 14:59:31 +0000
Subject: [New-bugs-announce] [issue4246] execution model - clear and
complete example in documentation
In-Reply-To: <1225551571.75.0.81232740458.issue4246@psf.upfronthosting.co.za>
Message-ID: <1225551571.75.0.81232740458.issue4246@psf.upfronthosting.co.za>
New submission from robwolfe <rw at smsnet.pl>:
I'd like to propose adding some complete example regarding scopes and
bindings resolving to execution model description.
There is no week on pl.comp.lang.python without a question about
UnboundLocalError problem. I'm getting tired answering that. ;-)
It does not have to look so verbose as my (attached) example, but please
add some example, which will clarify this issue.
----------
assignee: georg.brandl
components: Documentation
files: scopes.py
messages: 75441
nosy: georg.brandl, robwolfe
severity: normal
status: open
title: execution model - clear and complete example in documentation
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file11924/scopes.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4246>
_______________________________________
From report at bugs.python.org Sun Nov 2 03:16:03 2008
From: report at bugs.python.org (Sean Reifschneider)
Date: Sun, 02 Nov 2008 02:16:03 +0000
Subject: [New-bugs-announce] [issue4247] Docs: Provide some examples of
"pass" use in the tutorial.
In-Reply-To: <1225592163.24.0.267149626837.issue4247@psf.upfronthosting.co.za>
Message-ID: <1225592163.24.0.267149626837.issue4247@psf.upfronthosting.co.za>
New submission from Sean Reifschneider <jafo at tummy.com>:
I'm giving a Python tutorial to a bunch of local people and have decided
to use the Python.org tutorial to go by. One of the things I found I
wanted in the section on the "pass" statement was more information about
it's use. But I also think it's worth mentioning using the
NotImplementedError if pass is used for stubbing out code.
This patch to the tutorial includes some example use cases, and also a
reference to NotImplementedError. I would appreciate some review
however, as I'm not sure this discussion is appropriate.
Included below is the patch, for ease of reading, but it's also attached as
a patch (taken against trunk today).
Sean
===========
Index: Doc/tutorial/controlflow.rst
===================================================================
--- Doc/tutorial/controlflow.rst (revision 67072)
+++ Doc/tutorial/controlflow.rst (working copy)
@@ -166,7 +166,36 @@
... pass # Busy-wait for keyboard interrupt (Ctrl+C)
...
+This is commonly used for creating minimal classes like with exceptions, or
+for skipping unwanted exceptions::
+ >>> class ParserError(Exception):
+ ... pass
+ ...
+ >>> try:
+ ... import audioop
+ ... except ImportError:
+ ... pass
+ ...
+
+Another place it can be used is as a place-holder for a function or
+conditional body when you are working on new code, allowing you to keep
+thinking at a more abstract level. However, as :keyword:`pass` is silently
+ignored, a better choice may be to raise a :exc:`NotImplementedError`
+exception::
+
+ >>> def initlog(*args):
+ ... raise NotImplementedError # Open logfile if not already open
+ ... if not logfp:
+ ... raise NotImplementedError # Set up dummy log back-end
+ ... raise NotImplementedError # Call log initialization handler
+ ...
+
+If :keyword:`pass` were used here and you later ran tests, they may fail
+without indicating why. Using :exc:`NotImplementedError` causes this code
+to raise an exception, allowing you to tell exactly where code that you
+need to complete is.
+
.. _tut-functions:
Defining Functions
----------
assignee: fdrake
components: Documentation
files: pass-examples.patch
keywords: easy, needs review, patch, patch
messages: 75452
nosy: fdrake, jafo
priority: normal
severity: normal
status: open
title: Docs: Provide some examples of "pass" use in the tutorial.
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file11926/pass-examples.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4247>
_______________________________________
From report at bugs.python.org Sun Nov 2 05:32:24 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 02 Nov 2008 04:32:24 +0000
Subject: [New-bugs-announce] [issue4248] "class in None" in html help keyword
In-Reply-To: <1225600344.66.0.90175485782.issue4248@psf.upfronthosting.co.za>
Message-ID: <1225600344.66.0.90175485782.issue4248@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
I noticed built-in class `set` uses "set (class in None)" as index
keyword. Please see attached file "snapshot.png".
I think "set (builtin class)" or something is better.
----------
assignee: georg.brandl
components: Documentation, Windows
files: snapshot.png
messages: 75453
nosy: georg.brandl, ocean-city
severity: normal
status: open
title: "class in None" in html help keyword
versions: Python 2.6
Added file: http://bugs.python.org/file11927/snapshot.png
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4248>
_______________________________________
From report at bugs.python.org Sun Nov 2 15:56:55 2008
From: report at bugs.python.org (Jon Perez)
Date: Sun, 02 Nov 2008 14:56:55 +0000
Subject: [New-bugs-announce] [issue4249] HTTPResponse instance has no
attribute 'code'
In-Reply-To: <1225637815.26.0.704125161046.issue4249@psf.upfronthosting.co.za>
Message-ID: <1225637815.26.0.704125161046.issue4249@psf.upfronthosting.co.za>
New submission from Jon Perez <jbperez808 at yahoo.com>:
In http_response in HTTPErrorProcessor, the following line
code, msg, hdrs = response.code, response.msg, response.info()
results in an error because response.code is not a valid
attribute, changing it to response.status works, but is
this the correct bug fix?
See
http://www.linuxquestions.org/questions/linux-newbie-8/problem-with-yum-fedora-9-670586/
Traceback (most recent call last):
File "/usr/bin/yum", line 30, in <module>
yummain.main(sys.argv[1:])
File "/usr/share/yum/yummain.py", line 233, in main
clientStuff.get_package_info_from_servers(serverlist, HeaderInfo)
File "/usr/share/yum/clientStuff.py", line 846, in
get_package_info_from_servers
progress_obj=None)
File "/usr/share/yum/clientStuff.py", line 1327, in grab
bandwidth, conf.retries, retrycodes, checkfunc)
File "/usr/share/yum/urlgrabber.py", line 237, in retrygrab
progress_obj, throttle, bandwidth)
File "/usr/share/yum/urlgrabber.py", line 314, in urlgrab
fo = urllib2.urlopen(url)
File "/usr/lib/python2.5/urllib2.py", line 121, in urlopen
return _opener.open(url, data)
File "/usr/lib/python2.5/urllib2.py", line 380, in open
response = meth(req, response)
File "/usr/lib/python2.5/urllib2.py", line 487, in http_response
code, msg, hdrs = response.code, response.msg, response.info()
AttributeError: HTTPResponse instance has no attribute 'code'
----------
components: Library (Lib)
messages: 75454
nosy: jbperz808
severity: normal
status: open
title: HTTPResponse instance has no attribute 'code'
type: behavior
versions: Python 2.4, Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4249>
_______________________________________
From report at bugs.python.org Sun Nov 2 15:57:17 2008
From: report at bugs.python.org (Jon Perez)
Date: Sun, 02 Nov 2008 14:57:17 +0000
Subject: [New-bugs-announce] [issue4250] urllib2.py: HTTPResponse instance
has no attribute 'code'
In-Reply-To: <1225637837.09.0.0534571588639.issue4250@psf.upfronthosting.co.za>
Message-ID: <1225637837.09.0.0534571588639.issue4250@psf.upfronthosting.co.za>
New submission from Jon Perez <jbperez808 at yahoo.com>:
In http_response() in HTTPErrorProcessor in urllib2.py, the following line
code, msg, hdrs = response.code, response.msg, response.info()
results in an error because response.code is not a valid
attribute, changing it to response.status works, but is
this the correct bug fix?
See
http://www.linuxquestions.org/questions/linux-newbie-8/problem-with-yum-fedora-9-670586/
Traceback (most recent call last):
File "/usr/bin/yum", line 30, in <module>
yummain.main(sys.argv[1:])
File "/usr/share/yum/yummain.py", line 233, in main
clientStuff.get_package_info_from_servers(serverlist, HeaderInfo)
File "/usr/share/yum/clientStuff.py", line 846, in
get_package_info_from_servers
progress_obj=None)
File "/usr/share/yum/clientStuff.py", line 1327, in grab
bandwidth, conf.retries, retrycodes, checkfunc)
File "/usr/share/yum/urlgrabber.py", line 237, in retrygrab
progress_obj, throttle, bandwidth)
File "/usr/share/yum/urlgrabber.py", line 314, in urlgrab
fo = urllib2.urlopen(url)
File "/usr/lib/python2.5/urllib2.py", line 121, in urlopen
return _opener.open(url, data)
File "/usr/lib/python2.5/urllib2.py", line 380, in open
response = meth(req, response)
File "/usr/lib/python2.5/urllib2.py", line 487, in http_response
code, msg, hdrs = response.code, response.msg, response.info()
AttributeError: HTTPResponse instance has no attribute 'code'
----------
components: Library (Lib)
messages: 75455
nosy: jbperz808
severity: normal
status: open
title: urllib2.py: HTTPResponse instance has no attribute 'code'
type: behavior
versions: Python 2.4, Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4250>
_______________________________________
From report at bugs.python.org Sun Nov 2 22:51:45 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Sun, 02 Nov 2008 21:51:45 +0000
Subject: [New-bugs-announce] [issue4251] library.pdf documentation: "See
also: Module <xxx>" does not link to xxx inside the PDF File
In-Reply-To: <1225662705.73.0.76676836667.issue4251@psf.upfronthosting.co.za>
Message-ID: <1225662705.73.0.76676836667.issue4251@psf.upfronthosting.co.za>
New submission from Winfried Plappert <Winfried.Plappert at gmx.de>:
I take chapter "19.12 base64?RFC 3548: Base16, Base32, Base64 Data
Encodings" (Python 2.6) as an example. At the bottom of the chapter, you
find references to other resouces, in this case:
See Also:
Module binascii Support module containing ASCII-to-binary and
binary-to-ASCII conversions.
RFC 1521 - MIME (Multipurpose Internet Mail Extensions) Part One:
Mechanisms for Specifying and Describing the Format of Section 5.2,
?Base64 Content-Transfer-Encoding,? provides the definition of the
base64 encoding.
Interestingly enough RFC 1521 points to a web page (the link has been
removed in the current HTML documentation).
However "Module binascii" does not link to binascii in the library.pdf,
whereas the HTML documentation nicely links to
http://docs.python.org/library/binascii.html.
The file base64.rst IMO indicates that a link should be produced:
.. seealso::
Module :mod:`binascii`
Support module containing ASCII-to-binary and binary-to-ASCII
conversions.
:rfc:`1521` - MIME (Multipurpose Internet Mail Extensions) Part One:
Mechanisms for Specifying and Describing the Format of Internet Message
Bodies
Section 5.2, "Base64 Content-Transfer-Encoding," provides the
definition of the
base64 encoding.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 75456
nosy: georg.brandl, wplappert
severity: normal
status: open
title: library.pdf documentation: "See also: Module <xxx>" does not link to xxx inside the PDF File
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4251>
_______________________________________
From report at bugs.python.org Mon Nov 3 02:44:27 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 03 Nov 2008 01:44:27 +0000
Subject: [New-bugs-announce] [issue4252] inactive item not shown in html
help index pane
In-Reply-To: <1225676667.33.0.363387463486.issue4252@psf.upfronthosting.co.za>
Message-ID: <1225676667.33.0.363387463486.issue4252@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
Please see index_on_firefox.png and index_on_htmlhelp.png. "and" is
inactive item not linking to any page, but this item is not shown in
htmlhelp.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: index_on_firefox.png
messages: 75459
nosy: georg.brandl, ocean-city
severity: normal
status: open
title: inactive item not shown in html help index pane
versions: Python 2.6
Added file: http://bugs.python.org/file11929/index_on_firefox.png
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4252>
_______________________________________
From report at bugs.python.org Mon Nov 3 09:18:44 2008
From: report at bugs.python.org (Marcus CM)
Date: Mon, 03 Nov 2008 08:18:44 +0000
Subject: [New-bugs-announce] [issue4253] Maildir dumpmessage on
In-Reply-To: <1225700324.91.0.938996340802.issue4253@psf.upfronthosting.co.za>
Message-ID: <1225700324.91.0.938996340802.issue4253@psf.upfronthosting.co.za>
New submission from Marcus CM <marcus at internetnowasp.net>:
When using maildir on windows, the maildir._dump_message erronously
added "\r\n" to "\r\r\n" : in mailbox.py
target.write(buffer.read().replace('\n', os.linesep))
----------
components: Library (Lib)
messages: 75463
nosy: marcus at internetnowasp.net
severity: normal
status: open
title: Maildir dumpmessage on
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4253>
_______________________________________
From report at bugs.python.org Mon Nov 3 16:02:09 2008
From: report at bugs.python.org (Roland Brickl)
Date: Mon, 03 Nov 2008 15:02:09 +0000
Subject: [New-bugs-announce] [issue4254] _cursesmodule.c callable
update_lines_cols()
In-Reply-To: <1225724529.97.0.843166149521.issue4254@psf.upfronthosting.co.za>
Message-ID: <1225724529.97.0.843166149521.issue4254@psf.upfronthosting.co.za>
New submission from Roland Brickl <nemesis at bluesunset.de>:
curses.update_lines.cols() are normally usable within c programs. With
this change, it can now be used too. It only calls the preexisting
function that where only used internally. The cast in the return
statement are possibly false? But it works.
Because this aren't a big change, it would apply to some more
python-versions.
----------
components: Extension Modules
files: _curses.diff
keywords: patch
messages: 75464
nosy: nemesis
severity: normal
status: open
title: _cursesmodule.c callable update_lines_cols()
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file11932/_curses.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4254>
_______________________________________
From report at bugs.python.org Mon Nov 3 17:03:03 2008
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 03 Nov 2008 16:03:03 +0000
Subject: [New-bugs-announce] [issue4255] timing module refers to
non-existent documentation
In-Reply-To: <1225728183.22.0.203004248032.issue4255@psf.upfronthosting.co.za>
Message-ID: <1225728183.22.0.203004248032.issue4255@psf.upfronthosting.co.za>
New submission from Steven D'Aprano <steve at pearwood.info>:
import timing
help(timing)
=> MODULE DOCS
http://www.python.org/doc/current/lib/module-timing.html
but there doesn't appear to be any such page: the URL gives Error 404:
File Not Found. Searching the reference library for "timing" doesn't
find anything that looks relevant.
----------
assignee: georg.brandl
components: Documentation
messages: 75466
nosy: georg.brandl, stevenjd
severity: normal
status: open
title: timing module refers to non-existent documentation
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4255>
_______________________________________
From report at bugs.python.org Mon Nov 3 17:30:54 2008
From: report at bugs.python.org (Andy Buckley)
Date: Mon, 03 Nov 2008 16:30:54 +0000
Subject: [New-bugs-announce] [issue4256] optparse: provide a simple way to
get a programmatically useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
New submission from Andy Buckley <andy at insectnation.org>:
optparse is a great option parser, but one thing that would make it even
greater would be if it provided a standard option (cf. --help) which
lists all the available options in a parseable form. Something prefixed
with --help, e.g. --help-options would be ideal since it doesn't clutter
the option namespace.
This would provide a simple command-line hook for e.g. bash completion
customisation with complete/compgen, which could then easily and
maintainably obtain the list of available switches via the
--help-options flag rather than hard-coding the option names or
attempting to grep the output of --help
It would also be good if the OptionParser provided a simple Python API
way to obtain the names of all option switches, rather than having to
loop over OptionGroups, calling the unadvertised 'option_list' and
'get_option_name' methods!
----------
components: Library (Lib)
messages: 75469
nosy: andybuckley
severity: normal
status: open
title: optparse: provide a simple way to get a programmatically useful list of options
type: feature request
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________
From report at bugs.python.org Mon Nov 3 20:46:40 2008
From: report at bugs.python.org (Roy Smith)
Date: Mon, 03 Nov 2008 19:46:40 +0000
Subject: [New-bugs-announce] [issue4257] Documentation for
socket.gethostname() needs tweaking
In-Reply-To: <1225741600.75.0.864264407654.issue4257@psf.upfronthosting.co.za>
Message-ID: <1225741600.75.0.864264407654.issue4257@psf.upfronthosting.co.za>
New submission from Roy Smith <roy at panix.com>:
The docs say:
Return a string containing the hostname of the machine where the Python
interpreter is currently executing. If you want to know the current
machine's IP address, you may want to use gethostbyname(gethostname()).
This operation assumes...
It is not clear what the referent of "This" is. Are you saying that
gethostname() itself makes that assumption, or the use of gethostbyname()
to turn what gethostname() returns into an address makes that assumption?
I think it's the latter, but the sentence should be reworded to make it
clear.
----------
assignee: georg.brandl
components: Documentation
messages: 75476
nosy: georg.brandl, roysmith
severity: normal
status: open
title: Documentation for socket.gethostname() needs tweaking
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4257>
_______________________________________
From report at bugs.python.org Tue Nov 4 11:45:12 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 Nov 2008 10:45:12 +0000
Subject: [New-bugs-announce] [issue4258] Use 30-bit digits instead of 15-bit
digits for Python integers.
In-Reply-To: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
Message-ID: <1225795512.12.0.546973896448.issue4258@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
Here's an experimental patch, against the py3k branch, that makes Python
represent its long integers internally in base 2**30 instead of base
2**15, on platforms that have 32-bit and 64-bit integers available.
On platforms for which autoconf is unable to find both 32-bit and 64-bit
integers, the representation falls back to the usual one.
See also issue 1814 (GMP for longs), and the discussion at
http://mail.python.org/pipermail/python-dev/2008-November/083315.html
(note particularly Tim Peter's message at:
http://mail.python.org/pipermail/python-dev/2008-November/083355.html
)
----------
components: Interpreter Core
files: 30bit_longdigit.patch
keywords: patch
messages: 75491
nosy: marketdickinson
severity: normal
status: open
title: Use 30-bit digits instead of 15-bit digits for Python integers.
type: performance
versions: Python 3.1
Added file: http://bugs.python.org/file11935/30bit_longdigit.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4258>
_______________________________________
From report at bugs.python.org Tue Nov 4 22:34:07 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 04 Nov 2008 21:34:07 +0000
Subject: [New-bugs-announce] [issue4259] Update pydoc URLs
In-Reply-To: <1225834447.95.0.927155878948.issue4259@psf.upfronthosting.co.za>
Message-ID: <1225834447.95.0.927155878948.issue4259@psf.upfronthosting.co.za>
New submission from A.M. Kuchling <lists at amk.ca>:
The URL for module documentation generated by pydoc is no longer valid.
The attached patch corrects it for Python 2.5.3 by assembling the URL
using the Python version.
This patch shouldn't be forward-ported to 2.6 or 2.7; Sphinx changes the
URL pattern further, and 2.6 and 2.7 take this into account and get
their URLs correct.
----------
files: pydoc-patch.txt
messages: 75509
nosy: akuchling
severity: normal
status: open
title: Update pydoc URLs
versions: Python 2.5.3
Added file: http://bugs.python.org/file11943/pydoc-patch.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4259>
_______________________________________
From report at bugs.python.org Wed Nov 5 06:51:03 2008
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 05 Nov 2008 05:51:03 +0000
Subject: [New-bugs-announce] [issue4260] ctypes.xFUNCTYPE are decorators.
In-Reply-To: <1225864263.85.0.365773038706.issue4260@psf.upfronthosting.co.za>
Message-ID: <1225864263.85.0.365773038706.issue4260@psf.upfronthosting.co.za>
New submission from David W. Lambert <lambertdw at corning.com>:
http://docs.python.org/dev/3.0/library/ctypes.html#callback-functions
ctypes.xFUNCTYPE are another opportunity to advertise decorators.
Please consider inserting yet another qsort example written as a
decorator, perhaps as follows. Or---it could be that I'm slow and the
average pythonista will figure this out on first read.
@CFUNCTYPE(c_int, POINTER(c_int), POINTER(c_int))
def py_cmp_func(*args):
(a,b,) = (t[0] for t in args)
print("py_cmp_func", a, b)
return a-b
qsort(ia,len(ia),sizeof(c_int),py_cmp_func)
----------
assignee: georg.brandl
components: Documentation
messages: 75515
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: ctypes.xFUNCTYPE are decorators.
type: feature request
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4260>
_______________________________________
From report at bugs.python.org Wed Nov 5 09:19:22 2008
From: report at bugs.python.org (=?utf-8?q?Peter_=C3=85strand?=)
Date: Wed, 05 Nov 2008 08:19:22 +0000
Subject: [New-bugs-announce] [issue4261] The pwd module doesn't distinguish
between errors and no user
In-Reply-To: <1225873162.85.0.693443096685.issue4261@psf.upfronthosting.co.za>
Message-ID: <1225873162.85.0.693443096685.issue4261@psf.upfronthosting.co.za>
New submission from Peter ?strand <astrand at users.sourceforge.net>:
The getpwnam function in the pwd module does not correctly distinguish
between the case when the user does not exist and error
conditions. getpwnam() returns NULL in both cases, the the calling
code needs to check errno to determine if an error occured or not.
This bug is problematic in conjunction with bug
https://bugzilla.redhat.com/show_bug.cgi?id=470003, since it means
that Pythons getpwnam() will sometimes raise KeyError even for valid
users. How to reproduce:
$ python
Python 2.4.3 (#1, Jan 14 2008, 18:32:40)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-14)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pwd
>>> pwd.getpwnam("astrand")
('astrand', '*', 164, 20164, 'Peter Astrand', '/home/astrand', '/bin/bash')
>>>
>>> pwd.getpwnam("astrand")
Traceback (most recent call last):
File "<stdin>", line 1, in ?
KeyError: 'getpwnam(): name not found: astrand'
>>>
>>> pwd.getpwnam("astrand")
('astrand', '*', 164, 20164, 'Peter Astrand', '/home/astrand', '/bin/bash')
>>>
I was restarting the OpenLDAP server between the first successful call
and the traceback one.
----------
components: Library (Lib)
messages: 75516
nosy: astrand
severity: normal
status: open
title: The pwd module doesn't distinguish between errors and no user
type: behavior
versions: Python 2.4
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4261>
_______________________________________
From report at bugs.python.org Wed Nov 5 11:57:28 2008
From: report at bugs.python.org (Mark Seaborn)
Date: Wed, 05 Nov 2008 10:57:28 +0000
Subject: [New-bugs-announce] [issue4262] import and compile() do not treat
trailing whitespace the same
In-Reply-To: <1225882648.97.0.627285996609.issue4262@psf.upfronthosting.co.za>
Message-ID: <1225882648.97.0.627285996609.issue4262@psf.upfronthosting.co.za>
New submission from Mark Seaborn <mseaborn at cmedresearch.com>:
compile() raises a SyntaxError if the source code it is given contains
trailing spaces or a trailing carriage return character, but this does
happen if the same source code is imported or executed.
import subprocess
data = "if True:\n pass\n "
filename = "/tmp/test.py"
fh = open(filename, "w")
fh.write(data)
fh.close()
subprocess.check_call(["python", filename])
subprocess.check_call(["python", "-c", "import test"], cwd="/tmp")
compile(data, filename, "exec")
This gives:
Traceback (most recent call last):
File "whitespace.py", line 11, in <module>
compile(data, filename, "exec")
File "/tmp/test.py", line 3
SyntaxError: invalid syntax
This also happens if the data is changed to:
data = "if True:\n pass\r"
----------
components: Interpreter Core
messages: 75521
nosy: mseaborn
severity: normal
status: open
title: import and compile() do not treat trailing whitespace the same
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4262>
_______________________________________
From report at bugs.python.org Wed Nov 5 19:23:29 2008
From: report at bugs.python.org (Banesiu Sever)
Date: Wed, 05 Nov 2008 18:23:29 +0000
Subject: [New-bugs-announce] [issue4263] BufferedWriter non-blocking overage
In-Reply-To: <1225909409.69.0.679575967126.issue4263@psf.upfronthosting.co.za>
Message-ID: <1225909409.69.0.679575967126.issue4263@psf.upfronthosting.co.za>
New submission from Banesiu Sever <banesiu.sever at gmail.com>:
In some corner cases io.BufferedWriter raises an io.BlockingIOError
"lying" about the number of characters written.
I've added some tests and a small change to fix this issue.
----------
components: Library (Lib)
files: bw_overage.diff
keywords: patch
messages: 75523
nosy: banesiu.sever
severity: normal
status: open
title: BufferedWriter non-blocking overage
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file11945/bw_overage.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4263>
_______________________________________
From report at bugs.python.org Wed Nov 5 20:31:33 2008
From: report at bugs.python.org (David Turner)
Date: Wed, 05 Nov 2008 19:31:33 +0000
Subject: [New-bugs-announce] [issue4264] Patch: optimize code to use
LIST_APPEND instead of calling list.append
In-Reply-To: <1225913493.68.0.578631463812.issue4264@psf.upfronthosting.co.za>
Message-ID: <1225913493.68.0.578631463812.issue4264@psf.upfronthosting.co.za>
New submission from David Turner <novalis at novalis.org>:
This is a patch to Tom Lee's AST optimization branch.
Python bytecode includes at least one operation which is not directly
accessible from Python code: LIST_APPEND, which pops a value and a list
off the stack and appends the value to the list. This is used in
generating code for list comprehensions:
[x for x in somelist]
generates the following code for the body of the loop:
...
LOAD_FAST 1#a local is generated to hold the new list
LOAD_FAST 2 #the iteration variable, x
LIST_APPEND
...
Whereas if you were to try to write the comprehension directly, you
would get:
LOAD_FAST 1
LOAD_ATTR 0 #an index into the constant table: ?append?
LOAD_FAST 2
CALL_FUNCTION 1 #remove x and the append function from the top of the
stack and push the result of the call
POP_TOP
This is much slower. In part, it?s the cost of doing the attribute
lookup each time, which is why it?s common to see code like a = [] ap =
a.append for x in ?..: ap(x + ?) return a But the function call is
naturally slower than the simpler LIST_APPEND operation. The attached
patch tries to determine statically if a local is all circumstances
holds a list, and if so, generates LIST_APPEND whenever user code would
call local.append. It?s not perfect ? in particular, I could track
local types on a more fine-grained level than per-function. But it?s a
start.
----------
files: tlee-ast-optimize-appends.diff
keywords: patch
messages: 75525
nosy: novalis_dt
severity: normal
status: open
title: Patch: optimize code to use LIST_APPEND instead of calling list.append
Added file: http://bugs.python.org/file11946/tlee-ast-optimize-appends.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4264>
_______________________________________
From report at bugs.python.org Wed Nov 5 21:26:18 2008
From: report at bugs.python.org (Ammon Riley)
Date: Wed, 05 Nov 2008 20:26:18 +0000
Subject: [New-bugs-announce] [issue4265] shutil.copyfile() leaks file
descriptors when disk fills
In-Reply-To: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za>
Message-ID: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za>
New submission from Ammon Riley <ammon.riley at gmail.com>:
If the disk fills up during the copy operation, shutil.copyfile() leaks
file descriptors.
The problem is the order of the close() statements in the finally block.
In the event the copy operation runs out of disk space, the fdst.close()
call triggers an IOError, which prevents the fsrc.close() call from being
called.
Swapping the two calls, so that fsrc is closed first prevents this issue,
though it doesn't solve the underlying problem that IOErrors raised during
the close() operation will prevent the second close() from being called.
A probably better solution:
def copyfile(src, dst):
"""Copy data from src to dst"""
if _samefile(src, dst):
raise Error, "`%s` and `%s` are the same file" % (src, dst)
fsrc = None
fdst = None
try:
fsrc = open(src, 'rb')
fdst = open(dst, 'wb')
copyfileobj(fsrc, fdst)
finally:
try:
if fsrc:
fsrc.close()
finally:
if fdst:
fdst.close()
----------
components: Library (Lib)
messages: 75530
nosy: ammon_riley
severity: normal
status: open
title: shutil.copyfile() leaks file descriptors when disk fills
type: resource usage
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4265>
_______________________________________
From report at bugs.python.org Thu Nov 6 05:14:55 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 06 Nov 2008 04:14:55 +0000
Subject: [New-bugs-announce] [issue4266] Python 3.0 docs are broken.
In-Reply-To: <1225944895.19.0.930049319947.issue4266@psf.upfronthosting.co.za>
Message-ID: <1225944895.19.0.930049319947.issue4266@psf.upfronthosting.co.za>
New submission from Barry A. Warsaw <barry at python.org>:
The Python 3.0 documentation is broken. This is blocking the 3.0rc2
release.
I'm too tired right now to figure out what the base problem is.
This was during the ".../release.py --export 3.0rc2" build phase.
pdflatex 'c-api.tex'
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./c-api.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german,
ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch,
esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar,
norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish,
swedish, tur
kish, ukrainian, nohyphenation, loaded.
(./manual.cls
Document Class: manual 2008/10/18 Document class (Sphinx manual)
(/opt/local/share/texmf-dist/tex/latex/base/report.cls
Document Class: report 2004/02/16 v1.4f Standard LaTeX document class
(/opt/local/share/texmf-dist/tex/latex/base/size10.clo)))
(/opt/local/share/texmf-dist/tex/latex/base/inputenc.sty
(/opt/local/share/texmf-dist/tex/latex/base/utf8.def
(/opt/local/share/texmf-dist/tex/latex/base/t1enc.dfu)
(/opt/local/share/texmf-dist/tex/latex/base/ot1enc.dfu)
(/opt/local/share/texmf-dist/tex/latex/base/omsenc.dfu)))
(/opt/local/share/texmf-dist/tex/latex/base/fontenc.sty
(/opt/local/share/texmf-dist/tex/latex/base/t1enc.def))
(/opt/local/share/texmf-dist/tex/generic/babel/babel.sty
(/opt/local/share/texmf-dist/tex/generic/babel/english.ldf
(/opt/local/share/texmf-dist/tex/generic/babel/babel.def)))
(/opt/local/share/texmf-dist/tex/latex/psnfss/times.sty) (./fncychap.sty)
(./sphinx.sty (/opt/local/share/texmf-dist/tex/latex/base/textcomp.sty
(/opt/local/share/texmf-dist/tex/latex/base/ts1enc.def
(/opt/local/share/texmf-dist/tex/latex/base/ts1enc.dfu)))
(/opt/local/share/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty)
(/opt/local/share/texmf-dist/tex/latex/fancybox/fancybox.sty
Style option: `fancybox' v1.3 <2000/09/19> (tvz)
) (/opt/local/share/texmf-dist/tex/latex/titlesec/titlesec.sty)
(./tabulary.sty
(/opt/local/share/texmf-dist/tex/latex/tools/array.sty))
(/opt/local/share/texmf-dist/tex/latex/amsmath/amsmath.sty
For additional information on amsmath, use the `?' option.
(/opt/local/share/texmf-dist/tex/latex/amsmath/amstext.sty
(/opt/local/share/texmf-dist/tex/latex/amsmath/amsgen.sty))
(/opt/local/share/texmf-dist/tex/latex/amsmath/amsbsy.sty)
(/opt/local/share/texmf-dist/tex/latex/amsmath/amsopn.sty))
(/opt/local/share/texmf-dist/tex/latex/base/makeidx.sty)
(/opt/local/share/texmf-dist/tex/latex/framed/framed.sty)
(/opt/local/share/texmf-dist/tex/latex/graphics/color.sty
(/opt/local/share/texmf-dist/tex/latex/graphics/color.cfg)
(/opt/local/share/texmf-dist/tex/latex/graphics/pdftex.def))
(/opt/local/share/texmf-dist/tex/latex/fancyvrb/fancyvrb.sty
Style option: `fancyvrb' v2.6, with DG/SPQR fixes <1998/07/17> (tvz)
(/opt/local/share/texmf-dist/tex/latex/graphics/keyval.sty)
No file fancyvrb.cfg.
) (/opt/local/share/texmf-dist/tex/latex/graphics/graphicx.sty
(/opt/local/share/texmf-dist/tex/latex/graphics/graphics.sty
(/opt/local/share/texmf-dist/tex/latex/graphics/trig.sty)
(/opt/local/share/texmf-dist/tex/latex/graphics/graphics.cfg)))
(/opt/local/share/texmf-dist/tex/plain/pdfcolor/pdfcolor.tex)
! Extra \fi.
l.62 \fi\fi
?
----------
assignee: georg.brandl
components: Documentation
messages: 75544
nosy: barry, georg.brandl
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Python 3.0 docs are broken.
type: compile error
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4266>
_______________________________________
From report at bugs.python.org Thu Nov 6 08:48:17 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 06 Nov 2008 07:48:17 +0000
Subject: [New-bugs-announce] [issue4267] sqlite3 documentation
In-Reply-To: <1225957697.4.0.46686050905.issue4267@psf.upfronthosting.co.za>
Message-ID: <1225957697.4.0.46686050905.issue4267@psf.upfronthosting.co.za>
New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:
Three small changes to sqlite3 documentation:
1) (mostly cosmetic) In the second example, changed what was "a tuple
of tuples" to "a list of tuples" to follow common practice.
2) "DEFERRED", "IMMEDIATE" and "EXLUSIVE" (possible values for
Connection.isolation_level) are strings, not module constants, so
should be surrounded with quotes.
2) The iterdump example is not well written. Currently says:
con = sqlite3.connect('existing_db.db')
full_dump = os.linesep.join(con.iterdump())
f = open('dump.sql', 'w')
f.writelines(full_dump)
f.close()
Using os.linesep to join lines to be written to a text file has strange
results in non-Unix systems; joining the *whole* database dump into a
big string isn't a good idea; and finally, writelines(some_string) will
write the text one char at a time (!).
I've rewritten it as:
with open('dump.sql', 'w') as f:
for line in con.iterdump():
f.write('%s\n' % line)
to take advantage of iterdump's lazy nature.
----------
assignee: georg.brandl
components: Documentation
files: sqlite3.diff
keywords: patch
messages: 75548
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: sqlite3 documentation
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11949/sqlite3.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4267>
_______________________________________
From report at bugs.python.org Thu Nov 6 10:48:12 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 06 Nov 2008 09:48:12 +0000
Subject: [New-bugs-announce] [issue4268] functions in email package listed
under wrong module
In-Reply-To: <1225964892.7.0.454643269656.issue4268@psf.upfronthosting.co.za>
Message-ID: <1225964892.7.0.454643269656.issue4268@psf.upfronthosting.co.za>
New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:
Functions message_from_string and message_from_file are documented as
belonging to the email.parser module, but in fact they live at the top
of the email package.
The .rst source looks fine, but the rendered html says
`email.parser.message_from_string`.
http://docs.python.org/library/email.parser.html#parser-class-api
Perhaps it's the `module:: email.parser` directive at the top?
A similar problem is in email.mime.rst; all the documented classes are
exposed at the top of the email package (i.e. should be email.MIMEBase,
not email.mime.MIMEBase)
----------
assignee: georg.brandl
components: Documentation
messages: 75554
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: functions in email package listed under wrong module
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4268>
_______________________________________
From report at bugs.python.org Thu Nov 6 11:39:40 2008
From: report at bugs.python.org (Berend-Jan Wever)
Date: Thu, 06 Nov 2008 10:39:40 +0000
Subject: [New-bugs-announce] [issue4269] Spaces not showing correctly in
"split()" documentation on
http://www.python.org/doc/2.5.2/lib/string-methods.html
In-Reply-To: <1225967980.7.0.461107867511.issue4269@psf.upfronthosting.co.za>
Message-ID: <1225967980.7.0.461107867511.issue4269@psf.upfronthosting.co.za>
New submission from Berend-Jan Wever <berendjanwever at gmail.com>:
Part of the text of the online documentation for the string.split() method:
<snip>
If sep is not specified or is None, a different splitting algorithm is
applied. First, whitespace characters (spaces, tabs, newlines, returns,
and formfeeds) are stripped from both ends. Then, words are separated by
arbitrary length strings of whitespace characters. Consecutive
whitespace delimiters are treated as a single delimiter ("'1 2
3'.split()" returns "['1', '2', '3']"). Splitting an empty string or a
string consisting of just whitespace returns an empty list.
</snip>
As you may have noticed, there should be multiple spaces in ("'1 2
3'.split()". If you look at the HTML source you will see that they are
there. However, because browsers rendering HTML by default replace
multiple space with a single space, they are not visible in the
documentation. This should be addressed by either using <PRE></PRE>
around the text to preserve formatting or by replacing all instances of
multiple spaces with instances of " ". I suspect this problem may
be elsewhere in the documentation as well.
----------
assignee: georg.brandl
components: Documentation
messages: 75558
nosy: SkyLined, georg.brandl
severity: normal
status: open
title: Spaces not showing correctly in "split()" documentation on http://www.python.org/doc/2.5.2/lib/string-methods.html
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4269>
_______________________________________
From report at bugs.python.org Thu Nov 6 18:30:44 2008
From: report at bugs.python.org (Mikhail Terekhov)
Date: Thu, 06 Nov 2008 17:30:44 +0000
Subject: [New-bugs-announce] [issue4270] struct module: pack/unpack and byte
order on x86_64
In-Reply-To: <1225992644.3.0.448967011031.issue4270@psf.upfronthosting.co.za>
Message-ID: <1225992644.3.0.448967011031.issue4270@psf.upfronthosting.co.za>
New submission from Mikhail Terekhov <termim at gmail.com>:
pack/unpack behavior changes unexpectedly depending on the byte order:
l:/tmp >uname -pmiovs
Linux #1 SMP 2008-10-14 22:17:43 +0200 x86_64 x86_64 x86_64 GNU/Linux
l:/tmp >python
python
Python 2.5.1 (r251:54863, Aug 1 2008, 00:35:20)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
import struct
>>> struct.pack(">L",0xdeadbeef)
struct.pack(">L",0xdeadbeef)
'\xde\xad\xbe\xef'
>>> struct.pack("L",0xdeadbeef)
struct.pack("L",0xdeadbeef)
'\xef\xbe\xad\xde\x00\x00\x00\x00'
>>> struct.pack("<L",0xdeadbeef)
struct.pack("<L",0xdeadbeef)
'\xef\xbe\xad\xde'
>>>
The length of the result above is 8 when no byte order is specified
and 4 when it is.
Another example:
>>> struct.pack("L",0xdeadbeef00000000)
'\x00\x00\x00\x00\xef\xbe\xad\xde'
>>> struct.pack("<L",0xdeadbeef00000000)
'\x00\x00\x00\x00'
>>> struct.pack("!L",0xdeadbeef00000000)
'\x00\x00\x00\x00'
>>> struct.pack("!L",0x12345678deadbeef)
'\xde\xad\xbe\xef'
>>> struct.pack("L",0x12345678deadbeef)
'\xef\xbe\xad\xdexV4\x12'
>>>
Last results look strange.
----------
components: Library (Lib)
messages: 75569
nosy: mmm77
severity: normal
status: open
title: struct module: pack/unpack and byte order on x86_64
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4270>
_______________________________________
From report at bugs.python.org Thu Nov 6 18:31:52 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Thu, 06 Nov 2008 17:31:52 +0000
Subject: [New-bugs-announce] [issue4271] conversion tool does not fix "from
Tkinter import N, E"
In-Reply-To: <1225992712.67.0.232141095111.issue4271@psf.upfronthosting.co.za>
Message-ID: <1225992712.67.0.232141095111.issue4271@psf.upfronthosting.co.za>
New submission from Winfried Plappert <Winfried.Plappert at gmx.de>:
I tried to check the tracker for an existing issue with the conversion
tool, but I could not find one. I am using the "python2.6
Python2.6/Tools/scripts/2to3 -w -v ." command to convert existing Python
scripts to Python3.0.
I made two observations:
1. Tkinter
from Tkinter import (N, E, ...) does NOT get translated to
from tkinter import (N, E, ...)
2. 2to3 produces relative imports for stuff which lives in the same
directory, but trying to compile the stuff, I get the error:
org: from global_stuff import *
2t3: from .global_stuff import *
ValueError: Attempted relative import in non-package
----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 75571
nosy: wplappert
severity: normal
status: open
title: conversion tool does not fix "from Tkinter import N,E"
type: compile error
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4271>
_______________________________________
From report at bugs.python.org Thu Nov 6 21:47:10 2008
From: report at bugs.python.org (Jacques Frechet)
Date: Thu, 06 Nov 2008 20:47:10 +0000
Subject: [New-bugs-announce] [issue4272] set timestamp in gzip stream
In-Reply-To: <1226004430.06.0.832608065072.issue4272@psf.upfronthosting.co.za>
Message-ID: <1226004430.06.0.832608065072.issue4272@psf.upfronthosting.co.za>
New submission from Jacques Frechet <jfrechet at users.sourceforge.net>:
The gzip header defined in RFC 1952 includes a mandatory "MTIME" field,
originally intended to contain the modification time of the original
uncompressed file. It is often ignored when decompressing, though
gunzip (for example) uses it to set the modification time of the output
file if applicable.
The Python gzip module always sets the MTIME field to the current time,
and always discards MTIME when decompressing. As a result, compressing
the same string using gzip produces different output every time. For
certain applications, especially those involving comparisons or
cryprographic signing of binary files, these spurious changes can be
quite inconvenient. Aside from the MTIME field, the gzip module already
produces entirely deterministic output.
I'm attaching a patch which adds an optional "mtime" argument to the
GzipFile class, giving the caller the option of providing a timestamp
when compressing. Default behavior is unchanged. I've included updated
documentation and three new test cases in the patch.
In order to facilitate testing, the patch also includes code to set the
"mtime" member of the GzipFile instance when decompressing. The first
test case uses the new member to ensure that the timestamp given to the
GzipFile constructor is preserved correctly. The second test checks for
specific values in the entire gzip header (not just the MTIME field) by
reading the compressed file directly, examining individual fields in a
(relatively) flexible way. The third compares the entire compressed
stream against a predetermined sequence of bytes in a relatively
inflexible way. All tests pass on my AMD64 box, and I expect them all
to pass on all supported platforms without any problems. However, If
anybody is concerned that any of the tests sound like they might be too
brittle, I'm certainly not overly attached to them.
If anyone has any further suggestions, I'd be delighted to submit a new
patch.
Thanks!
Jacques
----------
components: Library (Lib)
files: gzip-mtime-py3k.patch
keywords: patch
messages: 75580
nosy: jfrechet
severity: normal
status: open
title: set timestamp in gzip stream
type: feature request
Added file: http://bugs.python.org/file11954/gzip-mtime-py3k.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4272>
_______________________________________
From report at bugs.python.org Thu Nov 6 23:00:03 2008
From: report at bugs.python.org (darrenr)
Date: Thu, 06 Nov 2008 22:00:03 +0000
Subject: [New-bugs-announce] [issue4273] cycle created by profile.run
In-Reply-To: <1226008803.34.0.267825485061.issue4273@psf.upfronthosting.co.za>
Message-ID: <1226008803.34.0.267825485061.issue4273@psf.upfronthosting.co.za>
New submission from darrenr <python-roundup at dranalli.com>:
The profile module creates a reference cycle. See attached session.
----------
components: Library (Lib)
files: profile_cycle.txt
messages: 75582
nosy: darrenr
severity: normal
status: open
title: cycle created by profile.run
type: resource usage
versions: Python 2.4
Added file: http://bugs.python.org/file11956/profile_cycle.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4273>
_______________________________________
From report at bugs.python.org Fri Nov 7 04:13:52 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 07 Nov 2008 03:13:52 +0000
Subject: [New-bugs-announce] [issue4274] Finish what's new in 3.0
In-Reply-To: <1226027632.26.0.922705313094.issue4274@psf.upfronthosting.co.za>
Message-ID: <1226027632.26.0.922705313094.issue4274@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
The what's new section of the 3.0 docs need lots of extra care. It's
short and it doesn't list all PEPs and important changes. Since lot's of
people are coming from 2.5 it may also be a wise idea to list relevant
2.5->2.6 changes.
----------
assignee: akuchling
components: Documentation
messages: 75592
nosy: akuchling, barry, christian.heimes, georg.brandl, gvanrossum
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: Finish what's new in 3.0
type: feature request
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4274>
_______________________________________
From report at bugs.python.org Fri Nov 7 04:29:48 2008
From: report at bugs.python.org (Don MacMillen)
Date: Fri, 07 Nov 2008 03:29:48 +0000
Subject: [New-bugs-announce] [issue4275] socketserver example code not
correctly ported to py3k
In-Reply-To: <1226028588.03.0.646628975166.issue4275@psf.upfronthosting.co.za>
Message-ID: <1226028588.03.0.646628975166.issue4275@psf.upfronthosting.co.za>
New submission from Don MacMillen <don at macmillen.net>:
code examples in socketserver do not run in py3k
Obvious errors with print stmt (not function call)
Less obvious errors with socket.send that does not
accept str type (bytearray works fine). Client example
below shows problems.
import socket
import sys
HOST, PORT = "localhost", 9999
data = " ".join(sys.argv[1:])
# Create a socket (SOCK_STREAM means a TCP socket)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# Connect to server and send data
sock.connect((HOST, PORT))
sock.send(data + "\n")
# Receive data from the server and shut down
received = sock.recv(1024)
sock.close()
print "Sent: %s" % data
print "Received: %s" % received
----------
messages: 75595
nosy: macd
severity: normal
status: open
title: socketserver example code not correctly ported to py3k
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4275>
_______________________________________
From report at bugs.python.org Fri Nov 7 04:51:42 2008
From: report at bugs.python.org (Jan Schreuder)
Date: Fri, 07 Nov 2008 03:51:42 +0000
Subject: [New-bugs-announce] [issue4276] IDLE in 2.6 fails to launch
In-Reply-To: <1226029902.06.0.437223717006.issue4276@psf.upfronthosting.co.za>
Message-ID: <1226029902.06.0.437223717006.issue4276@psf.upfronthosting.co.za>
New submission from Jan Schreuder <jan9447 at mac.com>:
I downloaded and installed Python 2.6 for Mac OSX 10.4. It installed
Build Applet, Extras, IDLE and Python Launcher in a Python 2.6 folder in
the Applications folder. However, IDLE will not launch. I have Python
2.5 installed. That IDLE version works.
----------
components: IDLE
messages: 75596
nosy: JanKarel
severity: normal
status: open
title: IDLE in 2.6 fails to launch
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4276>
_______________________________________
From report at bugs.python.org Fri Nov 7 13:15:53 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 07 Nov 2008 12:15:53 +0000
Subject: [New-bugs-announce] [issue4277] asynchat's handle_error
inconsistency
In-Reply-To: <1226060153.34.0.769481825348.issue4277@psf.upfronthosting.co.za>
Message-ID: <1226060153.34.0.769481825348.issue4277@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:
Suppose you have tow sockets handled by two asynchat.async_chat class
instances and from class1 you want to send some data through class2:
class1(asynchat.async_chat):
...
def mymethod(self):
class2_instance.push_with_producer(producer)
Since push_with_producer automatically calls initiate_send() if an error
occurs while class2 reads the first chunk of data from the producer,
class1's handle_error gets called.
If the error occurs when reading the next chunks of data class2's
handle_error will be called instead.
This is an inconsistency that should be fixed so that always class2's
handle_error gets called.
The patch in attachment does that.
----------
components: Library (Lib)
files: asynchat.patch
keywords: patch
messages: 75601
nosy: giampaolo.rodola, josiah.carlson, josiahcarlson
severity: normal
status: open
title: asynchat's handle_error inconsistency
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file11959/asynchat.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4277>
_______________________________________
From report at bugs.python.org Fri Nov 7 14:13:55 2008
From: report at bugs.python.org (Keith Briggs)
Date: Fri, 07 Nov 2008 13:13:55 +0000
Subject: [New-bugs-announce] [issue4278] optparse quirks
In-Reply-To: <1226063635.77.0.234802837689.issue4278@psf.upfronthosting.co.za>
Message-ID: <1226063635.77.0.234802837689.issue4278@psf.upfronthosting.co.za>
New submission from Keith Briggs <kbriggs at users.sourceforge.net>:
I got the message:
optparse.OptionError: invalid long option string '-T0': must start with
--, followed by non-dash
This is bad - the real error was that I gave a short option which did
not have a single letter.
Also, it seems that add_option('--height-of-plot','-h') is not allowed,
because -h can only go with --help. How do I override this?
Keith
----------
components: Extension Modules
messages: 75602
nosy: kbriggs
severity: normal
status: open
title: optparse quirks
type: behavior
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4278>
_______________________________________
From report at bugs.python.org Fri Nov 7 14:58:20 2008
From: report at bugs.python.org (Andy)
Date: Fri, 07 Nov 2008 13:58:20 +0000
Subject: [New-bugs-announce] [issue4279] Module 'parser' fails to build
In-Reply-To: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
Message-ID: <1226066300.29.0.700541757582.issue4279@psf.upfronthosting.co.za>
New submission from Andy <flossyfriend at hotmail.com>:
With a clean checkout of the py3k source it fails to build the Parser
exension module (based on Modules/parsermodule.c) when building against
a cygwin target.
This appears to be related to the movement of the symbol
_PyParser_Grammar from graminit.c to Parser\metagrammar.c. (At least
this is where it was going by the code comments)
Because of this the module now requires Parser\metagrammar.c to get
this information via Py_meta_grammar.
The patch modifies setup.py to add the required file and modifies
parsermodule.c to use the accessor function.
(This fails on a clean trunk build in the same way as well - which
makes me very suspicious that this is not a "real" issue as the
buildbots seem to be green.)
My gut feeling is that my modification to setup.py for the module is
incorrect - it just looks messy. So I await the inevitable: "That's not
how to fix it...." :-)
----------
components: Extension Modules
files: parsermodule_fix.diff
keywords: patch
messages: 75603
nosy: kirkshorts
severity: normal
status: open
title: Module 'parser' fails to build
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file11960/parsermodule_fix.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4279>
_______________________________________
From report at bugs.python.org Fri Nov 7 20:55:02 2008
From: report at bugs.python.org (Colin J. Williams)
Date: Fri, 07 Nov 2008 19:55:02 +0000
Subject: [New-bugs-announce] [issue4280] Version Checker
In-Reply-To: <1226087702.6.0.0754542760086.issue4280@psf.upfronthosting.co.za>
Message-ID: <1226087702.6.0.0754542760086.issue4280@psf.upfronthosting.co.za>
New submission from Colin J. Williams <cjw at ncf.ca>:
Versions 2.5, 2.6 and 3.0 contain a Version Checker in the Tools directory.
This appears to no longer serve a useful purpose.
Perhaps it can be dropped from the distribution.
Colin W
----------
components: Tests
files: pyversioncheck.py
messages: 75611
nosy: cjw
severity: normal
status: open
title: Version Checker
type: feature request
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11962/pyversioncheck.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4280>
_______________________________________
From report at bugs.python.org Fri Nov 7 21:32:00 2008
From: report at bugs.python.org (Vlastimil Brom)
Date: Fri, 07 Nov 2008 20:32:00 +0000
Subject: [New-bugs-announce] [issue4281] Idle - incorrectly displaying a
character (Latin capital letter sharp s)
In-Reply-To: <1226089920.44.0.90680757022.issue4281@psf.upfronthosting.co.za>
Message-ID: <1226089920.44.0.90680757022.issue4281@psf.upfronthosting.co.za>
New submission from Vlastimil Brom <vlastimil.brom at gmail.com>:
While experimenting with the new unicodedata for version 5.1 (many
thanks for it!) I discovered some strange behaviour of Idle with regard
to a character not available in any font on my system, namely Latin
capital letter sharp s - U+1E9E.
Cf. the following sessions:
Python 3.0rc2 (r30rc2:67141, Nov 7 2008, 11:43:46) [MSC v.1500 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
...
IDLE 3.0rc2
>>> print("\N{LATIN CAPITAL LETTER SHARP S}")
?
>>> print("\N{LATIN CAPITAL LETTER S WITH CEDILLA}")
?
>>> print("\N{PHAGS-PA LETTER KA}")
?
>>> print("\ufff0")
?
>>> hex(ord("?"))
'0x1e9e'
>>> hex(ord("?"))
'0x15e'
>>>
Of course, the exact view cannot be copied, but basically I see very
similar glyphs for the first two characters, while I had expected a
"square"-sign or something for the first one; this is what I get with
other surely unavailable glyph as well as a non existent character. See
the attached screenshot.
However, the characters remain clearly distinguished, as can be seen
e.g. after copying them as a parameter of ord(...).
Python 2.6 behaves the same way:
=======================
Python 2.6 (r26:66721, Oct 2 2008, 11:35:03) [MSC v.1500 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
...
IDLE 2.6
>>> print u"\N{LATIN CAPITAL LETTER SHARP S}"
?
>>>
...
==============================================
Not that it is much important, but I found it a bit surprising. I'm
using WinXPh SP3 Czech.
----------
components: IDLE, Tkinter, Unicode
files: idle-capital-sharp-s.jpg
messages: 75613
nosy: vbr
severity: normal
status: open
title: Idle - incorrectly displaying a character (Latin capital letter sharp s)
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11963/idle-capital-sharp-s.jpg
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4281>
_______________________________________
From report at bugs.python.org Sat Nov 8 03:49:32 2008
From: report at bugs.python.org (Takafumi SHIDO)
Date: Sat, 08 Nov 2008 02:49:32 +0000
Subject: [New-bugs-announce] [issue4282] (Python3) The profile module
deesn't understand the character set definition
In-Reply-To: <1226112572.15.0.185589671168.issue4282@psf.upfronthosting.co.za>
Message-ID: <1226112572.15.0.185589671168.issue4282@psf.upfronthosting.co.za>
New submission from Takafumi SHIDO <takafumi at shido.info>:
The profile module of Python3 deesn't understand the character set of
the script.
When a profile is executed (like $python -m profile -o prof.dat foo.py)
on a code (say foo.py) which defines its character set in the second
line (like #coding:utf-8),
the profile crashes with an error message like:
"SyntaxError: unknown encoding: utf-8"
----------
messages: 75627
nosy: shidot
severity: normal
status: open
title: (Python3) The profile module deesn't understand the character set definition
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4282>
_______________________________________
From report at bugs.python.org Sat Nov 8 13:56:30 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sat, 08 Nov 2008 12:56:30 +0000
Subject: [New-bugs-announce] [issue4283] "python3.0 setup.py install --user"
raises AttributeError
In-Reply-To: <1226148990.03.0.577410643236.issue4283@psf.upfronthosting.co.za>
Message-ID: <1226148990.03.0.577410643236.issue4283@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
A simple left-over "dict.iteritems". Patch is attached.
----------
components: Distutils
files: distutils.patch
keywords: patch
messages: 75634
nosy: hagen
severity: normal
status: open
title: "python3.0 setup.py install --user" raises AttributeError
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11965/distutils.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4283>
_______________________________________
From report at bugs.python.org Sat Nov 8 20:09:50 2008
From: report at bugs.python.org (Anthony Awtrey)
Date: Sat, 08 Nov 2008 19:09:50 +0000
Subject: [New-bugs-announce] [issue4284] Python 2.6 64-bit + Vista 64 = Bad
MSVCRT
In-Reply-To: <1226171390.73.0.943676496028.issue4284@psf.upfronthosting.co.za>
Message-ID: <1226171390.73.0.943676496028.issue4284@psf.upfronthosting.co.za>
New submission from Anthony Awtrey <tony at awtrey.com>:
Here is the reproduction process. Get Windows box running Vista 64-bit.
Download the Python 2.6 64-bit version. Write a script that imports
escape from saxutils. See this:
C:\Python26>python.exe example_xml_script.py > out.xml
Traceback (most recent call last):
File "example_xml_script.py", line 11, in <module>
from xml.sax.saxutils import escape
File "C:\Python26\lib\xml\sax\saxutils.py", line 6, in <module>
import os, urlparse, urllib, types
File "C:\Python26\lib\urllib.py", line 26, in <module>
import socket
File "C:\Python26\lib\socket.py", line 46, in <module>
import _socket
ImportError: DLL load failed: The application has failed to start
because its side-by-side configuration is incorrect. Please see the
application event log for more detail.
EventViewer says:
Activation context generation failed for "C:\Python26\DLLs\_socket.pyd".
Error in manifest or policy file
"C:\Python26DLLs\Microsoft.VC90.CRT.MANIFEST" on line 12.
The value "../msvcr90.dll" of attribute "name" in element
"urn:schemas-microsoft-com:asm.v1^file" is invalid.
Go download the MSVCRT directly and install it:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en
Then the problem goes away.
This issue is particular only to the Python 2.6 64-bit version, as the
32-bit version runs just fine.
----------
components: Windows
messages: 75643
nosy: DaGoodBoy
severity: normal
status: open
title: Python 2.6 64-bit + Vista 64 = Bad MSVCRT
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4284>
_______________________________________
From report at bugs.python.org Sun Nov 9 01:04:52 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 09 Nov 2008 00:04:52 +0000
Subject: [New-bugs-announce] [issue4285] Use a named tuple for
sys.version_info
In-Reply-To: <1226189092.93.0.524804334834.issue4285@psf.upfronthosting.co.za>
Message-ID: <1226189092.93.0.524804334834.issue4285@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
sys.version_info is just asking for a named tuple consisting of major,
minor, micro, releaselevel, and serial.
This is assuming, of course, that bootstrapping doesn't get in the way.
----------
assignee: brett.cannon
components: Extension Modules
keywords: easy
messages: 75647
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Use a named tuple for sys.version_info
type: behavior
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4285>
_______________________________________
From report at bugs.python.org Sun Nov 9 02:28:25 2008
From: report at bugs.python.org (dlfjessup)
Date: Sun, 09 Nov 2008 01:28:25 +0000
Subject: [New-bugs-announce] [issue4286] Discrepancy in format string
documentation
In-Reply-To: <1226194105.16.0.0970163310493.issue4286@psf.upfronthosting.co.za>
Message-ID: <1226194105.16.0.0970163310493.issue4286@psf.upfronthosting.co.za>
New submission from dlfjessup <dljessup at gmail.com>:
In the documentation for Format Strings
(http://docs.python.org/dev/3.0/library/string.html#formatstrings), the
grammar has the following rule:
> conversion ::= "r" | "s"
However, the documentation later reads:
> Three conversion flags are currently supported: '!s' which calls str()
on the value, '!r' which calls repr() and '!a' which calls ascii().
This implies that the correct rule for the grammar is:
> conversion ::= "a" | "r" | "s"
----------
assignee: georg.brandl
components: Documentation
messages: 75648
nosy: dlfjessup, georg.brandl
severity: normal
status: open
title: Discrepancy in format string documentation
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4286>
_______________________________________
From report at bugs.python.org Sun Nov 9 02:33:59 2008
From: report at bugs.python.org (Fernando Correia)
Date: Sun, 09 Nov 2008 01:33:59 +0000
Subject: [New-bugs-announce] [issue4287] Broken URL in documentation style
guide
In-Reply-To: <1226194439.54.0.969230784102.issue4287@psf.upfronthosting.co.za>
Message-ID: <1226194439.54.0.969230784102.issue4287@psf.upfronthosting.co.za>
New submission from Fernando Correia <fernandoacorreia at gmail.com>:
The documentation Style Guide
[http://docs.python.org/dev/documenting/style.html] has a broken link to
http://developer.apple.com/documentation/UserExperience/Conceptual/APStyleGuide/AppleStyleGuide2006.pdf.
This link should be updated to:
http://developer.apple.com/documentation/UserExperience/Conceptual/APStyleGuide/APSG_2008.pdf
----------
assignee: georg.brandl
components: Documentation
messages: 75649
nosy: facorreia, georg.brandl
severity: normal
status: open
title: Broken URL in documentation style guide
type: feature request
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4287>
_______________________________________
From report at bugs.python.org Sun Nov 9 13:34:30 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 09 Nov 2008 12:34:30 +0000
Subject: [New-bugs-announce] [issue4288] parsermodule and grammar variable
In-Reply-To: <1226234070.01.0.954871233884.issue4288@psf.upfronthosting.co.za>
Message-ID: <1226234070.01.0.954871233884.issue4288@psf.upfronthosting.co.za>
New submission from Roumen Petrov <bugtrack at roumenpetrov.info>:
After synchronization of my mingw32 cross-compilation environment with
trunk some of tests fail. The reason is that parsermodule fail to link.
Please check build on officially supported platform: MSVC and cygwin.
The attached patch (parser-grammar.patch) solve issue in my environment.
----------
components: Build, Tests
files: parser-grammar.patch
keywords: patch
messages: 75652
nosy: rpetrov
severity: normal
status: open
title: parsermodule and grammar variable
versions: Python 2.6
Added file: http://bugs.python.org/file11969/parser-grammar.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4288>
_______________________________________
From report at bugs.python.org Sun Nov 9 13:54:33 2008
From: report at bugs.python.org (Fabio Zadrozny)
Date: Sun, 09 Nov 2008 12:54:33 +0000
Subject: [New-bugs-announce] [issue4289] Python 2.6 installer crashes when
selecting 'advanced' and cancelling it
In-Reply-To: <1226235273.93.0.0512251767655.issue4289@psf.upfronthosting.co.za>
Message-ID: <1226235273.93.0.0512251767655.issue4289@psf.upfronthosting.co.za>
New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:
When installing python-2.6.msi it crashes when doing the following steps
on a windows XP (32 bit).
I'm not sure if all those steps are needed, but that's how it crashed here:
- start python-2.6.msi
- check 'install just for me'
- change the destination directory (d:\bin\Python26)
- click on 'advanced'
- click on cancel
- confirm cancel
At this point windows presents a message: to help protect your computer,
Windows has closed this program.
----------
components: Installation
messages: 75653
nosy: fabioz
severity: normal
status: open
title: Python 2.6 installer crashes when selecting 'advanced' and cancelling it
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4289>
_______________________________________
From report at bugs.python.org Mon Nov 10 00:04:13 2008
From: report at bugs.python.org (Ondrej Certik)
Date: Sun, 09 Nov 2008 23:04:13 +0000
Subject: [New-bugs-announce] [issue4290] 2to3 fails with sympy
In-Reply-To: <1226271853.32.0.445399161713.issue4290@psf.upfronthosting.co.za>
Message-ID: <1226271853.32.0.445399161713.issue4290@psf.upfronthosting.co.za>
New submission from Ondrej Certik <ondrej at certik.cz>:
Download my branch of sympy from here:
http://github.com/certik/sympy/tree/division3
and run the 2to3 tool with python2.5:
$ python2.5 ../2to3/2to3 sympy/
[...]
Traceback (most recent call last):
File "../2to3/2to3", line 6, in <module>
sys.exit(main("lib2to3.fixes"))
File "/home/ondra/repos/2to3/lib2to3/main.py", line 126, in main
rt.refactor(args, options.write, options.doctests_only)
File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 194, in refactor
self.refactor_dir(dir_or_file, write, doctests_only)
File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 212, in
refactor_dir
self.refactor_file(fullname, write, doctests_only)
File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 235, in
refactor_file
tree = self.refactor_string(input, filename)
File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 260, in
refactor_string
self.refactor_tree(tree, name)
File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 299, in
refactor_tree
self.traverse_by(self.post_order, tree.post_order())
File "/home/ondra/repos/2to3/lib2to3/refactor.py", line 323, in
traverse_by
new = fixer.transform(node, results)
File "/home/ondra/repos/2to3/lib2to3/fixes/fix_metaclass.py", line
148, in transform
if not has_metaclass(node):
File "/home/ondra/repos/2to3/lib2to3/fixes/fix_metaclass.py", line 34,
in has_metaclass
return has_metaclass(node)
File "/home/ondra/repos/2to3/lib2to3/fixes/fix_metaclass.py", line 39,
in has_metaclass
if leaf_node.value == '__metaclass__':
AttributeError: 'Node' object has no attribute 'value'
----------
messages: 75669
nosy: certik
severity: normal
status: open
title: 2to3 fails with sympy
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4290>
_______________________________________
From report at bugs.python.org Mon Nov 10 00:57:55 2008
From: report at bugs.python.org (Jeremy Banks)
Date: Sun, 09 Nov 2008 23:57:55 +0000
Subject: [New-bugs-announce] [issue4291] Allow Division of
datetime.timedelta Objects
In-Reply-To: <1226275075.64.0.889084103082.issue4291@psf.upfronthosting.co.za>
Message-ID: <1226275075.64.0.889084103082.issue4291@psf.upfronthosting.co.za>
New submission from Jeremy Banks <jeremy at jeremybanks.ca>:
It would be convenient if it were possible to divide one
datetime.timedelta object by another to determine their relative durations.
Were the datetime module pure Python a crude solution would just be to
add two methods like this:
def toMicroseconds(self):
return ((self.days * 24 * 60) + self.seconds * 1000000) +
self.microseconds
def __truediv__(self, other):
return self.toMicroseconds() / other.toMicroseconds()
However, I don't understand know the Python C API well enough to know
how to patch the C module.
----------
components: Library (Lib)
messages: 75670
nosy: Jeremy Banks
severity: normal
status: open
title: Allow Division of datetime.timedelta Objects
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4291>
_______________________________________
From report at bugs.python.org Mon Nov 10 08:03:55 2008
From: report at bugs.python.org (Ondrej Certik)
Date: Mon, 10 Nov 2008 07:03:55 +0000
Subject: [New-bugs-announce] [issue4292] 2to3 fails to convert "from
something import (a, b, c)"
In-Reply-To: <1226300635.16.0.0493266543071.issue4292@psf.upfronthosting.co.za>
Message-ID: <1226300635.16.0.0493266543071.issue4292@psf.upfronthosting.co.za>
New submission from Ondrej Certik <ondrej at certik.cz>:
While converting the SymPy repo:
the 2to3 failed to convert stuff like:
from something import (a, b, c, )
Attached find the patch that I had to do by hand -- I think 2to3 should
be able to fix this as well.
----------
files: import.patch
keywords: patch
messages: 75683
nosy: certik
severity: normal
status: open
title: 2to3 fails to convert "from something import (a, b, c)"
Added file: http://bugs.python.org/file11972/import.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4292>
_______________________________________
From report at bugs.python.org Mon Nov 10 12:36:35 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 10 Nov 2008 11:36:35 +0000
Subject: [New-bugs-announce] [issue4293] Thread Safe Py_AddPendingCall
In-Reply-To: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
Message-ID: <1226316995.54.0.445551761995.issue4293@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
At CCP We have started using the Py_AddPendingCall() mechanism to
signal python about a completed IO operation.
However, we noticed that the existing mechanism was hoplelessly un-
thread safe. This is bad, since on Windows at least, it is very
convenient to have such callbacks happen on an arbitrary thread from
the system's thread pool.
I submit a thread-safe implementation instead to be used if WITH_THREAD
is defined.
This allows Py_AddPendingCall() to be called from any thread, from any
context, even from a PendingCall callback itself.
----------
components: Interpreter Core
files: pendingalls.patch
keywords: needs review, patch, patch
messages: 75691
nosy: krisvale
priority: normal
severity: normal
status: open
title: Thread Safe Py_AddPendingCall
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file11974/pendingalls.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4293>
_______________________________________
From report at bugs.python.org Mon Nov 10 14:12:32 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Nov 2008 13:12:32 +0000
Subject: [New-bugs-announce] [issue4294] Macros for PyLong: sign,
number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
It's hard to read Objects/longobject.c because the code depends to
much on the implementation. I wrote macros to simplify the code:
- PyLong_SIGN(x)
- PyLong_EQUALS_ZERO(x)
- PyLong_FITS_INT(x)
- PyLong_GET_INT(x)
- PyLong_NDIGITS(x)
Macros are declared in Include/longintrepr.h to be able to use them
outside longobject.c. Eg. I used it in Modules/mathmodule.c.
The patch also contains extra changes:
- create sdigit type (used by PyLong_GET_INT(x))
- use memcpy() in _PyLong_Copy()
- use stwodigits in long_mul()
- replace many Py_SIZE() hacks by my macros (eg. see long_hash)
Using my patch, it will be easier to change long integer
implementation, like:
- Use 30-bit digits instead of 15-bit digits (issue #4258)
- Use GMP for PyLong (issue #1814)
Example of changes:
i = Py_SIZE(v);
x = 0;
if (i < 0) {
PyErr_SetString(PyExc_OverflowError,
"can't convert negative value to unsigned
int");
return (unsigned long) -1;
}
switch (i) {
case 0: return 0;
case 1: return v->ob_digit[0];
}
while (--i >= 0) {
...
is replaced by:
if (PyLong_SIGN(v) < 0) {
PyErr_SetString(PyExc_OverflowError,
"can't convert negative value to unsigned
int");
return (unsigned long) -1;
}
if (PyLong_FITS_INT(v))
return (unsigned long) PyLong_GET_INT(v);
x = 0;
i = PyLong_NDIGITS(v);
while (--i >= 0) {
...
----------
files: pylong_macros.patch
keywords: patch
messages: 75694
nosy: haypo
severity: normal
status: open
title: Macros for PyLong: sign, number of digits, fits in an int
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11975/pylong_macros.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4294>
_______________________________________
From report at bugs.python.org Mon Nov 10 23:57:12 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Mon, 10 Nov 2008 22:57:12 +0000
Subject: [New-bugs-announce] [issue4295] closing stdout in a child process
on cygwin means that process doesn't receive bytes from stdin
anymore. I think.
In-Reply-To: <1226357832.32.0.219991496484.issue4295@psf.upfronthosting.co.za>
Message-ID: <1226357832.32.0.219991496484.issue4295@psf.upfronthosting.co.za>
New submission from Zooko O'Whielacronx <zooko at zooko.com>:
When someone runs "bin/trial --reactor=select
twisted.internet.test.test_process.ProcessTestsBuilder_PollReactor.test_
childConnectionLost" on cygwin, using the cygwin version of Python,
either manually (which I've done on two cygwin installations), or from
the twisted buildbot --
http://buildbot.twistedmatrix.com/builders/cygwin-py2.5-select -- then
once the child process closes its fd #2, it subsequently receives no
further bytes from its fd #1, even though the parent process has written
some bytes to that pipe.
I can reproduce this by running the Twisted unit tests, like this:
step 1: get twisted:
svn co svn://svn.twistedmatrix.com/svn/Twisted/trunk twisted
step 2: cd into the top-level directory, and run trial:
cd twisted && python ./bin/trial --reactor=select
twisted.internet.test.test_process.ProcessTestsBuilder_PollReactor.test_
childConnectionLost
On other platforms that cygwin (see the Twisted buildbot --
http://buildbot.twistedmatrix.com/supported?branch=trunk -- then this
test exits quickly with success. On cygwin, using cygwin python.exe,
this test instead enter an infinite loop as the child waits to receive
further bytes on its stdin, and the parent waits for the child to
respond to those bytes. (This doesn't happen on cygwin with the standard
Win32 build of python.exe, of course, anymore than it happens on a
Windows system without cygwin installed when using that executable.)
I've opened a ticket about this on the twisted issue tracker as well:
http://twistedmatrix.com/trac/ticket/3529 # closing stdout in a child
process on cygwin means that process doesn't receive bytes from stdin
anymore. I think.
----------
components: Interpreter Core
messages: 75711
nosy: zooko
severity: normal
status: open
title: closing stdout in a child process on cygwin means that process doesn't receive bytes from stdin anymore. I think.
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4295>
_______________________________________
From report at bugs.python.org Tue Nov 11 02:44:42 2008
From: report at bugs.python.org (Michael B Curtis)
Date: Tue, 11 Nov 2008 01:44:42 +0000
Subject: [New-bugs-announce] [issue4296] Python assumes identity implies
equivalence; contradicts NaN
In-Reply-To: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
Message-ID: <1226367882.66.0.317704470575.issue4296@psf.upfronthosting.co.za>
New submission from Michael B Curtis <mikecurtis at gmail.com>:
Found in Python 2.4; not sure what other versions may be affected.
I noticed a contradiction with regards to equivalence when experimenting
with NaN, which has the special property that it "is" itself, but it
doesn't "==" itself:
>>> a = float('nan')
>>> a is a
True
>>> a == a
False
>>> b = [float('nan')]
>>> b is b
True
>>> b == b
True
I am not at all familiar with Python internals, but the issue appears to
be in PyObject_RichCompareBool of python/trunk/Objects/object.c
This method "Guarantees that identity implies equality". However, this
doesn't "Gaurantee" this fact, but instead "Assumes" it, because it is
not something that is always True. NaN is identical to itself, but not
equivalent to itself.
At a minimum, the contradiction introduced by this assumption should be
documented. However, it may be possible to do better, by fixing it.
The assumption appears to be made that identity should imply
equivalence, for the common case. Would it therefore be possible to,
instead of having objects such as lists perform this optimization and
make this assumption, instead have the base object types implement this
assumption. That is, for regular objects, when we evaluate equivalence,
we return True if the objects are identical. Then, the optimization can
be removed from objects such as list, so that when they check the
equivalence of each object, the optimization is performed there. NaN
can then override the default behavior, so that it always returns False
in equivalence comparisons.
----------
components: Interpreter Core
messages: 75716
nosy: mikecurtis
severity: normal
status: open
title: Python assumes identity implies equivalence; contradicts NaN
type: behavior
versions: Python 2.4
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4296>
_______________________________________
From report at bugs.python.org Tue Nov 11 15:22:59 2008
From: report at bugs.python.org (Daniel Watkins)
Date: Tue, 11 Nov 2008 14:22:59 +0000
Subject: [New-bugs-announce] [issue4297] Add error_log attribute to
optparse.OptionParser
In-Reply-To: <1226413379.99.0.188665223227.issue4297@psf.upfronthosting.co.za>
Message-ID: <1226413379.99.0.188665223227.issue4297@psf.upfronthosting.co.za>
New submission from Daniel Watkins <daniel at daniel-watkins.co.uk>:
I've recently had to subclass optparse.OptionParser, and copy-paste the
exit method, just to change where errors were printed to (I needed
stdout rather than stderr). I've also had a request from a client to
log errors with command-line parsing to a file, rather than to stdout.
So, this patch adds an error_log parameter to OptionParser.__init__
which is used instead of stderr internally (and, of course, defaults to
stderr).
----------
components: Library (Lib)
files: optparse-error_log.patch
keywords: patch
messages: 75741
nosy: odd_bloke
severity: normal
status: open
title: Add error_log attribute to optparse.OptionParser
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file11985/optparse-error_log.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4297>
_______________________________________
From report at bugs.python.org Tue Nov 11 16:07:51 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Tue, 11 Nov 2008 15:07:51 +0000
Subject: [New-bugs-announce] [issue4298] pickle segfault or MemoryError on
invalid input
In-Reply-To: <1226416071.17.0.696466187419.issue4298@psf.upfronthosting.co.za>
Message-ID: <1226416071.17.0.696466187419.issue4298@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
On a 64-bit build pickle.loads segfaults on the following bytes. (Same
for pickle.load on a corresponding file.) On a 32-bit build there is
only a MemoryError.
Python 3.0rc2 (r30rc2:67114, Nov 10 2008, 12:09:54)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> pickle.loads(bytes([0x58, 0, 0, 0, 0x54]))
Segmentation fault
----------
components: Library (Lib)
messages: 75743
nosy: hagen
severity: normal
status: open
title: pickle segfault or MemoryError on invalid input
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4298>
_______________________________________
From report at bugs.python.org Tue Nov 11 16:19:57 2008
From: report at bugs.python.org (Gary VanHorn)
Date: Tue, 11 Nov 2008 15:19:57 +0000
Subject: [New-bugs-announce] [issue4299] 3.0rc2.msi Install Fails (Error
Code 2755)
In-Reply-To: <1226416797.61.0.972163132872.issue4299@psf.upfronthosting.co.za>
Message-ID: <1226416797.61.0.972163132872.issue4299@psf.upfronthosting.co.za>
New submission from Gary VanHorn <support at toc247.com>:
Where can an error code resource be found?
----------
components: Installation
messages: 75744
nosy: sharksuit
severity: normal
status: open
title: 3.0rc2.msi Install Fails (Error Code 2755)
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4299>
_______________________________________
From report at bugs.python.org Tue Nov 11 20:04:02 2008
From: report at bugs.python.org (Brian D'Urso)
Date: Tue, 11 Nov 2008 19:04:02 +0000
Subject: [New-bugs-announce] [issue4300] error in multiprocessing logging
docs
In-Reply-To: <1226430242.52.0.860879245755.issue4300@psf.upfronthosting.co.za>
Message-ID: <1226430242.52.0.860879245755.issue4300@psf.upfronthosting.co.za>
New submission from Brian D'Urso <dursobr at pitt.edu>:
the 2.6 docs for the multiprocessing module have a minor error in the
logging example which causes it to fail:
the documentation says to get the logger with
'multiprocessing.get_logger()' which works
but the example uses 'multiprocessing.getLogger()' which uses the
logging package method name and is not valid.
The full example in the docs is:
>>> import multiprocessing, logging
>>> logger = multiprocessing.getLogger()
>>> logger.setLevel(logging.INFO)
>>> logger.warning('doomed')
[WARNING/MainProcess] doomed
>>> m = multiprocessing.Manager()
[INFO/SyncManager-1] child process calling self.run()
[INFO/SyncManager-1] manager bound to '\\\\.\\pipe\\pyc-2776-0-lj0tfa'
>>> del m
[INFO/MainProcess] sending shutdown message to manager
[INFO/SyncManager-1] manager exiting with exitcode 0
----------
assignee: georg.brandl
components: Documentation
messages: 75755
nosy: dursobr, georg.brandl
severity: normal
status: open
title: error in multiprocessing logging docs
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4300>
_______________________________________
From report at bugs.python.org Tue Nov 11 20:50:54 2008
From: report at bugs.python.org (Brian D'Urso)
Date: Tue, 11 Nov 2008 19:50:54 +0000
Subject: [New-bugs-announce] [issue4301] incorrect and inconsistent logging
in multiprocessing
In-Reply-To: <1226433054.6.0.61986495608.issue4301@psf.upfronthosting.co.za>
Message-ID: <1226433054.6.0.61986495608.issue4301@psf.upfronthosting.co.za>
New submission from Brian D'Urso <dursobr at pitt.edu>:
logging in multiprocessing seems to give inconsistent results on Linux
and XP, but neither appears to match the documentation:
According to the docs, when first created "the logger has level
logging.NOTSET and has a handler which sends output to sys.stderr using
format '[%(levelname)s/%(processName)s] %(message)s'" The example in the
docs also does not work, but the full problem is more clearly
illustrated with the following:
This should print a message from the main process and the subprocess:
import multiprocessing, logging
def f():
logger = multiprocessing.get_logger()
logger.info('info from subprocess')
if __name__ == '__main__':
logger = multiprocessing.get_logger()
logger.setLevel(logging.INFO)
logger.info('info from main process')
p = multiprocessing.Process(target=f)
p.start()
p.join()
but, on Windows (XP) and Linux (ScientificLinux 5.2, python 2.6 compiled
from src) it outputs only:
No handlers could be found for logger "multiprocessing"
We can 'fix' this by specifying a handler, as in:
import multiprocessing, logging
def f():
logger = multiprocessing.get_logger()
logger.info('info from subprocess')
if __name__ == '__main__':
logger = multiprocessing.get_logger()
logger.setLevel(logging.INFO)
handler = logging.StreamHandler()
handler.setLevel(logging.INFO)
formatter = logging.Formatter('[%(levelname)s/%(processName)s]
%(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)
logger.info('info from main process')
p = multiprocessing.Process(target=f)
p.start()
p.join()
Then on Linux I get:
[INFO/MainProcess] info from main process
[INFO/Process-1] child process calling self.run()
[INFO/Process-1] info from subprocess
[INFO/Process-1] process shutting down
[INFO/Process-1] process exiting with exitcode 0
[INFO/MainProcess] process shutting down
which looks better, but on Windows I get:
[INFO/MainProcess] info from main process
No handlers could be found for logger "multiprocessing"
[INFO/MainProcess] process shutting down
So, the logger is still not setup correctly in the subprocess on
Windows. We can again try to 'fix' this to:
import multiprocessing, logging
def f():
logger = multiprocessing.get_logger()
handler = logging.StreamHandler()
handler.setLevel(logging.INFO)
formatter = logging.Formatter('[%(levelname)s/%(processName)s]
%(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)
logger.info('info from subprocess')
if __name__ == '__main__':
logger = multiprocessing.get_logger()
logger.setLevel(logging.INFO)
handler = logging.StreamHandler()
handler.setLevel(logging.INFO)
formatter = logging.Formatter('[%(levelname)s/%(processName)s]
%(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)
logger.info('info from main process')
p = multiprocessing.Process(target=f)
p.start()
p.join()
Now, on Linux I get:
[INFO/MainProcess] info from main process
[INFO/Process-1] child process calling self.run()
[INFO/Process-1] info from subprocess
[INFO/Process-1] info from subprocess
[INFO/Process-1] process shutting down
[INFO/Process-1] process shutting down
[INFO/Process-1] process exiting with exitcode 0
[INFO/Process-1] process exiting with exitcode 0
[INFO/MainProcess] process shutting down
i.e. double output from the subprocess!
On Windows, I finally get:
[INFO/MainProcess] info from main process
No handlers could be found for logger "multiprocessing"
[INFO/Process-1] info from subprocess
[INFO/Process-1] process shutting down
[INFO/Process-1] process exiting with exitcode 0
[INFO/MainProcess] process shutting down
which is almost OK, but the logger is getting set up too late to pick up
the subprocess self.run
It seems like the logger is not being setup correctly by
multiprocessing.get_logger() and the behavior is different in a
subprocess on Windows vs Linux.
----------
components: Library (Lib)
messages: 75757
nosy: dursobr
severity: normal
status: open
title: incorrect and inconsistent logging in multiprocessing
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4301>
_______________________________________
From report at bugs.python.org Wed Nov 12 09:17:20 2008
From: report at bugs.python.org (Piers Lauder)
Date: Wed, 12 Nov 2008 08:17:20 +0000
Subject: [New-bugs-announce] [issue4302] smtplib.py initialisation defect
In-Reply-To: <1226477840.43.0.0037139980832.issue4302@psf.upfronthosting.co.za>
Message-ID: <1226477840.43.0.0037139980832.issue4302@psf.upfronthosting.co.za>
New submission from Piers Lauder <piers at it.usyd.edu.au>:
smtplib does not initialise the valriable 'sock' in the case where
'host' is NULL on instantiation of smtplib.SMTP.
Eg:
% python
Python 2.5.2 (r252:60911, Oct 5 2008, 19:29:17)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import smtplib
>>> client=smtplib.SMTP('')
>>> client.sendmail('from at home', 'to at home', 'test')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/smtplib.py", line 676, in sendmail
if not (200 <= self.ehlo()[0] <= 299):
File "/usr/lib/python2.5/smtplib.py", line 397, in ehlo
self.putcmd("ehlo", name or self.local_hostname)
File "/usr/lib/python2.5/smtplib.py", line 333, in putcmd
self.send(str)
File "/usr/lib/python2.5/smtplib.py", line 318, in send
if self.sock:
AttributeError: SMTP instance has no attribute 'sock'
>>>
The fix is to add "self.sock = None" in __init__ if host is not set,
and then the behaviour is much more helpful:
% python
Python 2.5.2 (r252:60911, Oct 5 2008, 19:29:17)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import smtplib
>>> client=smtplib.SMTP('')
>>> client.sendmail('from at home', 'to at home', 'test')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/smtplib.py", line 678, in sendmail
if not (200 <= self.ehlo()[0] <= 299):
File "/usr/lib/python2.5/smtplib.py", line 399, in ehlo
self.putcmd("ehlo", name or self.local_hostname)
File "/usr/lib/python2.5/smtplib.py", line 335, in putcmd
self.send(str)
File "/usr/lib/python2.5/smtplib.py", line 327, in send
raise SMTPServerDisconnected('please run connect() first')
smtplib.SMTPServerDisconnected: please run connect() first
>>>
----------
components: Library (Lib)
files: smtplib-diff-c
messages: 75777
nosy: piers
severity: normal
status: open
title: smtplib.py initialisation defect
type: behavior
versions: Python 2.5.3
Added file: http://bugs.python.org/file11991/smtplib-diff-c
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4302>
_______________________________________
From report at bugs.python.org Wed Nov 12 10:00:54 2008
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 12 Nov 2008 09:00:54 +0000
Subject: [New-bugs-announce] [issue4303] [2.5 regression] ctypes fails to
build on arm-linux-gnu
In-Reply-To: <1226480454.07.0.737656498235.issue4303@psf.upfronthosting.co.za>
Message-ID: <1226480454.07.0.737656498235.issue4303@psf.upfronthosting.co.za>
New submission from Matthias Klose <doko at debian.org>:
ctypes fails to build on arm-linux-gnu, see
http://python.org/dev/buildbot/2.5/ARM Linux 2.5/builds/3/step-compile/0
gcc -pthread -fPIC -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I.
-I/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/./Include
-Ibuild/temp.linux-armv5tel-2.5/libffi/include
-Ibuild/temp.linux-armv5tel-2.5/libffi
-I/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/libffi/src
-I. -IInclude -I./Include -I/usr/local/include
-I/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Include
-I/home/pybot/buildarea-arm/2.5.klose-linux-arm/build -c
/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/_ctypes.c
-o
build/temp.linux-armv5tel-2.5/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/_ctypes.o
In file included from
/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/_ctypes.c:127:
/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/ctypes.h:72:
error: expected specifier-qualifier-list before 'ffi_closure'
/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/_ctypes.c:
In function 'CFuncPtr_new':
/home/pybot/buildarea-arm/2.5.klose-linux-arm/build/Modules/_ctypes/_ctypes.c:2955:
error: 'CThunkObject' has no member named 'pcl'
this is a regression compared to 2.5.2. Not seen on 2.6 or 3.0. Please
consider a fix before 2.5.3 is released.
----------
messages: 75779
nosy: doko
priority: release blocker
severity: normal
status: open
title: [2.5 regression] ctypes fails to build on arm-linux-gnu
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4303>
_______________________________________
From report at bugs.python.org Wed Nov 12 10:34:41 2008
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 12 Nov 2008 09:34:41 +0000
Subject: [New-bugs-announce] [issue4304] build mode which fails for build
failures in extensions
In-Reply-To: <1226482481.6.0.943122034161.issue4304@psf.upfronthosting.co.za>
Message-ID: <1226482481.6.0.943122034161.issue4304@psf.upfronthosting.co.za>
New submission from Matthias Klose <doko at debian.org>:
as seen in issue4303, the buildbots don't complain about build failures
in extensions. it would be nice to have a mode, where the build fails
when an extension doesn't build, but is expected to build. exceptions to
this set of expected builds should be configurable.
----------
components: Build
messages: 75780
nosy: doko
severity: normal
status: open
title: build mode which fails for build failures in extensions
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4304>
_______________________________________
From report at bugs.python.org Wed Nov 12 11:00:01 2008
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 12 Nov 2008 10:00:01 +0000
Subject: [New-bugs-announce] [issue4305] ctypes fails to build on
mipsel-linux-gnu (detects mips instead of mipsel)
In-Reply-To: <1226484001.23.0.749041410677.issue4305@psf.upfronthosting.co.za>
Message-ID: <1226484001.23.0.749041410677.issue4305@psf.upfronthosting.co.za>
New submission from Matthias Klose <doko at debian.org>:
seen on the mipsel buildbot
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
Traceback (most recent call last):
File "./setup.py", line 1880, in <module>
main()
File "./setup.py", line 1875, in main
'Lib/smtpd.py']
File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/core.py",
line 152, in setup
dist.run_commands()
File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/dist.py",
line 975, in run_commands
self.run_command(cmd)
File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/dist.py",
line 995, in run_command
cmd_obj.run()
File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/command/build.py",
line 134, in run
self.run_command(cmd_name)
File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/cmd.py",
line 333, in run_command
self.distribution.run_command(command)
File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/dist.py",
line 995, in run_command
cmd_obj.run()
File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/command/build_ext.py",
line 343, in run
self.build_extensions()
File "./setup.py", line 201, in build_extensions
build_ext.build_extensions(self)
File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/command/build_ext.py",
line 469, in build_extensions
self.build_extension(ext)
File "./setup.py", line 234, in build_extension
if not self.configure_ctypes(ext):
File "./setup.py", line 1684, in configure_ctypes
execfile(ffi_configfile, globals(), fficonfig)
File "build/temp.linux-mips-2.7-pydebug/libffi/fficonfig.py", line 32,
in <module>
ffi_sources += ffi_platforms['MIPS']
KeyError: 'MIPS'
[47349 refs]
make: *** [sharedmods] Error 1
----------
assignee: theller
components: ctypes
messages: 75781
nosy: doko, theller
severity: normal
status: open
title: ctypes fails to build on mipsel-linux-gnu (detects mips instead of mipsel)
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4305>
_______________________________________
From report at bugs.python.org Wed Nov 12 14:16:32 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Nov 2008 13:16:32 +0000
Subject: [New-bugs-announce] [issue4306] email package with unicode
subject/body
In-Reply-To: <1226495792.65.0.232994796976.issue4306@psf.upfronthosting.co.za>
Message-ID: <1226495792.65.0.232994796976.issue4306@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
I never used the email package, so my issue is maybe not a bug. I'm
trying to send an email with diacritics in the subject and the body.
I'm french so it's natural to use characters not in the ASCII range. I
wrote this small program:
def main():
# coding: utf8
ADDRESS = 'victor.stinner at haypocalc.com'
from email.mime.text import MIMEText
msg = MIMEText('accent ???', 'plain', 'utf-8')
msg['Subject'] = 'sujet ???'
msg['From'] = ADDRESS
msg['To'] = ADDRESS
text = msg.as_string()
print("--- FLATTEN ---")
print(text)
return
import smtplib
client=smtplib.SMTP('smtp.free.fr')
client.sendmail(ADDRESS, ADDRESS, text)
client.quit()
main()
(remove the "return" to really send the email)
The problem:
(...)
File "/home/haypo/prog/py3k/Lib/email/generator.py", line 141, in
_write_headers
header_name=h, continuation_ws='\t')
File "/home/haypo/prog/py3k/Lib/email/header.py", line 189, in
__init__
self.append(s, charset, errors)
File "/home/haypo/prog/py3k/Lib/email/header.py", line 262, in
append
input_bytes = s.encode(input_charset, errors)
UnicodeEncodeError: 'ascii' codec can't encode characters in position
6-8: ordinal not in range(128)
I don't understand why it uses ASCII whereas I specified that I would
like to use the UTF-8 charset.
My attached patch reused the message charset to encode the headers,
but use ASCII if the header can be encoded as ASCII. The patch
included an unit test.
----------
components: Library (Lib)
files: email_mime_unicode.patch
keywords: patch
messages: 75784
nosy: haypo
severity: normal
status: open
title: email package with unicode subject/body
versions: Python 3.0
Added file: http://bugs.python.org/file11992/email_mime_unicode.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4306>
_______________________________________
From report at bugs.python.org Wed Nov 12 17:24:37 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 12 Nov 2008 16:24:37 +0000
Subject: [New-bugs-announce] [issue4307] inspect.FullArgSpec does not match
the docs
In-Reply-To: <1226507077.43.0.0744196805458.issue4307@psf.upfronthosting.co.za>
Message-ID: <1226507077.43.0.0744196805458.issue4307@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
The docs say that inspect.FullArgSpec is a named tuple
FullArgSpec(args, varargs, varkw, defaults, kwonlyargs, kwonlydefaults,
annotations)
However the implementation has "kwdefaults" instead of "kwonlydefaults".
The name in the docs seems to make more sense. A patch fixing this is
attached.
----------
components: Library (Lib)
files: inspect.patch
keywords: patch
messages: 75788
nosy: hagen
severity: normal
status: open
title: inspect.FullArgSpec does not match the docs
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11994/inspect.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4307>
_______________________________________
From report at bugs.python.org Wed Nov 12 17:41:21 2008
From: report at bugs.python.org (Chris Withers)
Date: Wed, 12 Nov 2008 16:41:21 +0000
Subject: [New-bugs-announce] [issue4308] repr of httplib.IncompleteRead is
stupid
In-Reply-To: <1226508081.14.0.590007271511.issue4308@psf.upfronthosting.co.za>
Message-ID: <1226508081.14.0.590007271511.issue4308@psf.upfronthosting.co.za>
New submission from Chris Withers <chris at simplistix.co.uk>:
The repr of httplib.IncompleteRead contains all the data in the read so far.
This is stupid. Consider the download of a 100Mb file which fails after
30Mb. You end up with 90Mb of text in the log entry logged with the
python logging framework
(eg: logger.error('Something bad happened',exc_info=True) )
----------
components: Library (Lib)
messages: 75789
nosy: cjw296
severity: normal
status: open
title: repr of httplib.IncompleteRead is stupid
type: resource usage
versions: Python 2.5, Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4308>
_______________________________________
From report at bugs.python.org Wed Nov 12 21:53:14 2008
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 12 Nov 2008 20:53:14 +0000
Subject: [New-bugs-announce] [issue4309] ctypes documentation
In-Reply-To: <1226523194.83.0.190505447778.issue4309@psf.upfronthosting.co.za>
Message-ID: <1226523194.83.0.190505447778.issue4309@psf.upfronthosting.co.za>
New submission from David W. Lambert <lambertdw at corning.com>:
'''
http://docs.python.org/dev/3.0/library/ctypes.html
Where web page says
>>> printf("An int %d, a double %f\n", 1234, c_double(3.14))
Integer 1234, double 3.1400001049
31
>>>
should instead read
>>> printf(c_char_p("An int %d, a double %f\n"), 1234, c_double(3.14))
An int 1234, a double 3.140000
31
Although the intent of the message is clear, it is inexact with
regard to "An int" and "a double". Core dump is bigger problem:
Processor: Dual-Core AMD Opteron(tm) Processor 2218
Python: Python 3.0rc1+ (py3k, Nov 5 2008, 14:44:46)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
core dumps by segmentation fault for all the printf examples without
specifying c_char_p("string").
'''
# this program succeeds
from ctypes import *
libc = CDLL("libc.so.6")
print(libc.printf(c_char_p("An int %d, a double %f\n"), 1234,
c_double(3.14)))
----------
assignee: georg.brandl
components: Documentation
messages: 75793
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: ctypes documentation
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4309>
_______________________________________
From report at bugs.python.org Wed Nov 12 22:07:25 2008
From: report at bugs.python.org (Kyle Brandt)
Date: Wed, 12 Nov 2008 21:07:25 +0000
Subject: [New-bugs-announce] [issue4310] Comparison of two ints returns
wrong result
In-Reply-To: <1226524045.46.0.613067395679.issue4310@psf.upfronthosting.co.za>
Message-ID: <1226524045.46.0.613067395679.issue4310@psf.upfronthosting.co.za>
New submission from Kyle Brandt <kyle at kbrandt.com>:
The attached program returns a false result on one of my computers with
a Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz processor. Is seems the
comparison of two int does not perform correctly. I have python 2.5.2
and 2.6.27-7-generic kernel.
The lines of interest are 89-71:
print type(f_p),type(largest),f_p,largest
if f_p > largest:
print 'foo'
largest = f_p
When running this code:
# python id_11-2.py | grep 70600
<type 'int'> <type 'int'> 70600674 51267216
# python id_11-2.py | grep foo #doesn't return anything
When I run the same code on another machine the end result of the
program is 70600674, whereas my current machine the end result is
51267216.
----------
files: id_11-2.py
messages: 75794
nosy: kbrandt
severity: normal
status: open
title: Comparison of two ints returns wrong result
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file11996/id_11-2.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4310>
_______________________________________
From report at bugs.python.org Wed Nov 12 23:35:23 2008
From: report at bugs.python.org (Alejandro)
Date: Wed, 12 Nov 2008 22:35:23 +0000
Subject: [New-bugs-announce] [issue4311] Race condition on Multiprocessing
module documentation
In-Reply-To: <1226529323.41.0.396977390286.issue4311@psf.upfronthosting.co.za>
Message-ID: <1226529323.41.0.396977390286.issue4311@psf.upfronthosting.co.za>
New submission from Alejandro <alejolp at alejolp.com>:
The "devel" documentation of the "Multiprocessing" module at the
"Exchanging objects between processes" section has the following example
snippet:
from multiprocessing import Process, Queue
def f(q):
q.put([42, None, 'hello'])
if __name__ == '__main__':
q = Queue()
p = Process(target=f, args=(q,))
p.start()
print q.get() # prints "[42, None, 'hello']"
p.join()
The last two lines should be swapped to avoid a race condition:
p.join()
print q.get() # prints "[42, None, 'hello']"
BTW, Nice work. Keep on going folks =)
----------
assignee: georg.brandl
components: Documentation
messages: 75804
nosy: alejolp, georg.brandl
severity: normal
status: open
title: Race condition on Multiprocessing module documentation
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4311>
_______________________________________
From report at bugs.python.org Thu Nov 13 14:18:16 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Thu, 13 Nov 2008 13:18:16 +0000
Subject: [New-bugs-announce] [issue4312] Unicode in distutils meta-data?
In-Reply-To: <1226582296.84.0.466381976068.issue4312@psf.upfronthosting.co.za>
Message-ID: <1226582296.84.0.466381976068.issue4312@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
http://docs.python.org/dev/3.0/distutils/setupscript.html#additional-meta-data
says "None of the string values may be Unicode.". How is this to be
interpreted (or changed) w.r.t. Python 3.0?
----------
assignee: georg.brandl
components: Documentation
messages: 75816
nosy: georg.brandl, hagen
severity: normal
status: open
title: Unicode in distutils meta-data?
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4312>
_______________________________________
From report at bugs.python.org Thu Nov 13 14:24:16 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Nov 2008 13:24:16 +0000
Subject: [New-bugs-announce] [issue4313] IDLE segfault at exit
In-Reply-To: <1226582656.91.0.74839544885.issue4313@psf.upfronthosting.co.za>
Message-ID: <1226582656.91.0.74839544885.issue4313@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
With Python 3.0 trunk on Ubuntu Gutsy, IDLE crashs at exit. gdb trace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210763072 (LWP 9441)]
0xb79ac133 in Tk_Free3DBorder () from /usr/lib/libtk8.4.so.0
(gdb) where
#0 0xb79ac133 in Tk_Free3DBorder () from /usr/lib/libtk8.4.so.0
#1 0xb7a3cb36 in TkTextFreeTag () from /usr/lib/libtk8.4.so.0
#2 0xb7a2aef1 in ?? () from /usr/lib/libtk8.4.so.0
#3 0x084ade70 in ?? ()
#4 0x084b2410 in ?? ()
#5 0xbfecb248 in ?? ()
#6 0xb798e518 in ?? () from /usr/lib/libtcl8.4.so.0
#7 0xbfecb250 in ?? ()
#8 0x084ade84 in ?? ()
#9 0xbfecb268 in ?? ()
#10 0xb798e518 in ?? () from /usr/lib/libtcl8.4.so.0
#11 0x084ade84 in ?? ()
#12 0x00000001 in ?? ()
#13 0x00000000 in ?? ()
----------
messages: 75817
nosy: haypo
severity: normal
status: open
title: IDLE segfault at exit
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4313>
_______________________________________
From report at bugs.python.org Thu Nov 13 15:39:38 2008
From: report at bugs.python.org (ZooKeeper)
Date: Thu, 13 Nov 2008 14:39:38 +0000
Subject: [New-bugs-announce] [issue4314] isalpha bug
In-Reply-To: <1226587178.29.0.702800191925.issue4314@psf.upfronthosting.co.za>
Message-ID: <1226587178.29.0.702800191925.issue4314@psf.upfronthosting.co.za>
New submission from ZooKeeper <zooregs at mail.ru>:
This may be a little tricky to recreate but here it is:
q = u'??????'
q.isalpha()
True
foo = u'?'
foo.isalpha()
False
So the Russian character u'?' and u'?' as well as a bunch of others is
not recognized by isalpha as a alphabetic character, which it is a
matter of fact.
This applies to both capital and regular versions of the letters.
http://en.wikipedia.org/wiki/%D0%81
http://en.wikipedia.org/wiki/Che_(Cyrillic)
Using: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win32
----------
components: Extension Modules, Unicode
messages: 75820
nosy: ZooKeeper
severity: normal
status: open
title: isalpha bug
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4314>
_______________________________________
From report at bugs.python.org Thu Nov 13 17:06:13 2008
From: report at bugs.python.org (Silas S. Brown)
Date: Thu, 13 Nov 2008 16:06:13 +0000
Subject: [New-bugs-announce] [issue4315] On some Python builds,
exec in a function can't create shadows of variables if these are
declared "global" in another function of the same module
In-Reply-To: <1226592373.02.0.139711229291.issue4315@psf.upfronthosting.co.za>
Message-ID: <1226592373.02.0.139711229291.issue4315@psf.upfronthosting.co.za>
New submission from Silas S. Brown <ssb22 at users.sourceforge.net>:
Here's the example code:
setting1 = "val1"
setting2 = "val2"
def dummy():
global setting1
def f(x):
d ={"setting1":setting1,"setting2":setting2}
exec(x) in d
return d['setting1'], d['setting2']
print f("setting1=setting2='new'")
Expected result: ('new', 'new')
Actual result: ('val1', 'new')
The presence of "global setting1" in a different function effectively
stops a shadowed setting1 from being created by the exec.
Workaround: Add a real assignment before the exec, i.e.:
def f(x):
setting1 = 0
exec(x)
return setting1, setting2
or do the exec in a dictionary instead of in the current scope.
Observed in:
Python 2.5.1 (r251:54863, May 18 2007, 16:56:43) on Cygwin
Python 2.5.2 on 2.6.26-gentoo-r1 (by Christopher Faylor
http://www.cygwin.com/ml/cygwin/2008-11/msg00168.html )
Not observed in:
Python 2.5.1 (r251:54863, Aug 1 2008, 00:32:16) on SUSE Linux
Python 2.4.4 (#2, Apr 17 2008, 01:58:28) (Debian etch, ARM)
Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22) (Ubuntu)
----------
components: None
messages: 75829
nosy: ssb22
severity: normal
status: open
title: On some Python builds, exec in a function can't create shadows of variables if these are declared "global" in another function of the same module
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4315>
_______________________________________
From report at bugs.python.org Thu Nov 13 21:28:10 2008
From: report at bugs.python.org (Soren jacobsen)
Date: Thu, 13 Nov 2008 20:28:10 +0000
Subject: [New-bugs-announce] [issue4316] Improper use of [] in configure.in
leads to useless regexp in configure
In-Reply-To: <1226608090.37.0.571135469469.issue4316@psf.upfronthosting.co.za>
Message-ID: <1226608090.37.0.571135469469.issue4316@psf.upfronthosting.co.za>
New submission from Soren jacobsen <snj at NetBSD.org>:
"NetBSD/1.6[A-S]" is what is desired in configure, but the wrong
configure.in goop is used, so "NetBSD/1.6A-S" is generated instead.
Apply the attached patch, commit configure.in, run autoreconf, commit
configure.
----------
components: Build
files: netbsd-configure-in.diff
keywords: patch
messages: 75835
nosy: snj
severity: normal
status: open
title: Improper use of [] in configure.in leads to useless regexp in configure
type: compile error
Added file: http://bugs.python.org/file12000/netbsd-configure-in.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4316>
_______________________________________
From report at bugs.python.org Thu Nov 13 23:57:50 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 13 Nov 2008 22:57:50 +0000
Subject: [New-bugs-announce] [issue4317] Buffer overflow in imageop module
In-Reply-To: <1226617070.72.0.385940972603.issue4317@psf.upfronthosting.co.za>
Message-ID: <1226617070.72.0.385940972603.issue4317@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
The interpreter sometimes segfaults when running the test suite, in
test_imageop.
A more reliable crasher is:
>>> import imageop
>>> s = "A" * 32000
>>> imageop.rgb2rgb8(s, 1, len(s))
The failure was recently introduced by r66689, a "security fix" :-(
and backported today in 2.4!
This is a 2.4 release blocker. Patch is attached, please review.
----------
files: rgbcrash.diff
keywords: needs review, patch
messages: 75840
nosy: amaury.forgeotdarc
priority: release blocker
severity: normal
status: open
title: Buffer overflow in imageop module
type: crash
versions: Python 2.4, Python 2.6
Added file: http://bugs.python.org/file12001/rgbcrash.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4317>
_______________________________________
From report at bugs.python.org Fri Nov 14 01:37:45 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 14 Nov 2008 00:37:45 +0000
Subject: [New-bugs-announce] [issue4318] optparse: formatting of help
text/descriptions
In-Reply-To: <1226623065.62.0.674807245437.issue4318@psf.upfronthosting.co.za>
Message-ID: <1226623065.62.0.674807245437.issue4318@psf.upfronthosting.co.za>
New submission from A.M. Kuchling <lists at amk.ca>:
(Copied from an anonymous submission
in the Optik bug tracker.)
There have been some recent discussions on comp.lang.python about the
optparse/optik module, and Steve Bethard suggested you might be interested
in some of the work done there. I don't know if you'd find any of this
helpful for inclusion in Optik/optparse, but Steve says it's come up on
your mailing list too.
The problem at hand involves formatting help-strings so that they respect
newlines. Simply passing formatted help-strings off to the textwrap.*
methods mungs the newlines and loses them.
The original thread:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/6df6e6
b541a15bc2/acf1d05cad60fc45?#acf1d05cad60fc45
My solution:
http://groups.google.com/group/comp.lang.python/msg/09f28e26af0699b1
Dan then asked about it, and took my solution and ran with it:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/e72dee
e779d9989b/4ec68cd2a35d52e1?hl=en#4ec68cd2a35d52e1
Feel free to do with it as you like.
----------
components: Library (Lib)
messages: 75846
nosy: akuchling
severity: normal
status: open
title: optparse: formatting of help text/descriptions
type: feature request
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4318>
_______________________________________
From report at bugs.python.org Fri Nov 14 01:39:22 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 14 Nov 2008 00:39:22 +0000
Subject: [New-bugs-announce] [issue4319] optparse and non-ascii help strings
In-Reply-To: <1226623162.39.0.530373397898.issue4319@psf.upfronthosting.co.za>
Message-ID: <1226623162.39.0.530373397898.issue4319@psf.upfronthosting.co.za>
New submission from A.M. Kuchling <lists at amk.ca>:
(copied from the Optik bug tracker)
Related bug:
http://www.mail-archive.com/python-bugs-list at python.org/msg07227.html
Hi all,
It seems to me that the workaround to the above bug in optparse.py versio
1.5.3 introduces a new bug when help strings are byte strings (as opposed
to unicode) containing non-ascii characters. Consider the following
script:
$ cat test.py
#!/usr/bin/env python
# -*- coding:latin-1 -*-
import optparse
parser = optparse.OptionParser()
parser.add_option("--test",help="This does not work: ?")
parser.parse_args()
When called with "$ ./test.py --help", this script fails with the following
traceback:
$ ./test.py -h
Traceback (most recent call last):
File "./test.py", line 7, in <module>
parser.parse_args()
File "/usr/lib/python2.5/optparse.py", line 1385, in parse_args
stop = self._process_args(largs, rargs, values)
File "/usr/lib/python2.5/optparse.py", line 1429, in _process_args
self._process_short_opts(rargs, values)
File "/usr/lib/python2.5/optparse.py", line 1536, in _process_short_opts
option.process(opt, value, values, self)
File "/usr/lib/python2.5/optparse.py", line 782, in process
self.action, self.dest, opt, value, values, parser)
File "/usr/lib/python2.5/optparse.py", line 804, in take_action
parser.print_help()
File "/usr/lib/python2.5/optparse.py", line 1655, in print_help
file.write(self.format_help().encode(encoding, "replace"))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 117:
ordinal not in range(128)
This behaviour can be reproduced with utf-8 encoded strings as well.
If I understand correctly, line 1655 of optparse.py only works if
format_help() returns an ascii byte string or a unicode string, but the
call to "encoding" fails when it is a byte string containing non-ascii
character.
I think this is either a bug and should be fixed, or very misleading (and
should be fixed too :).
I hope to have helped even a little.
Thanks for optparse, and keep up the good work!
Cheers,
Antoine
----------
components: Library (Lib)
messages: 75847
nosy: akuchling
severity: normal
status: open
title: optparse and non-ascii help strings
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4319>
_______________________________________
From report at bugs.python.org Fri Nov 14 01:40:47 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 14 Nov 2008 00:40:47 +0000
Subject: [New-bugs-announce] [issue4320] optparse: "1 2 3" should be seen as
one string
In-Reply-To: <1226623247.3.0.318499239033.issue4320@psf.upfronthosting.co.za>
Message-ID: <1226623247.3.0.318499239033.issue4320@psf.upfronthosting.co.za>
New submission from A.M. Kuchling <lists at amk.ca>:
(copied from the Optik bug tracker -- I haven't tried
to replicate this.)
----------
components: Library (Lib)
messages: 75848
nosy: akuchling
severity: normal
status: open
title: optparse: "1 2 3" should be seen as one string
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4320>
_______________________________________
From report at bugs.python.org Fri Nov 14 07:03:31 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Fri, 14 Nov 2008 06:03:31 +0000
Subject: [New-bugs-announce] [issue4321] unintended syntax error with
decorators, parenthesis, and dots?
In-Reply-To: <1226642611.77.0.508088542922.issue4321@psf.upfronthosting.co.za>
Message-ID: <1226642611.77.0.508088542922.issue4321@psf.upfronthosting.co.za>
New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:
I believe I found an unintentional syntax error with a combination of
decorators, parenthesis, and dots. Here's a demonstration:
class C:
def prop(self, function):
return property(function)
class F:
@C().prop
def foo(self):
return 5
Which errors out with:
File "foo.py", line 6
@C().prop
^
SyntaxError: invalid syntax
I can't imagine why this would be desired, since these equivalent forms
work:
class D:
def foo(self):
return 5
foo = C().prop(foo)
class E:
c = C()
@c.prop
def foo(self):
return 5
----------
components: Interpreter Core
messages: 75850
nosy: erickt
severity: normal
status: open
title: unintended syntax error with decorators, parenthesis, and dots?
type: compile error
versions: Python 2.5.3, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4321>
_______________________________________
From report at bugs.python.org Fri Nov 14 07:44:18 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Fri, 14 Nov 2008 06:44:18 +0000
Subject: [New-bugs-announce] [issue4322] function with modified __name__
uses original name when there's an arg error
In-Reply-To: <1226645058.7.0.820357853432.issue4322@psf.upfronthosting.co.za>
Message-ID: <1226645058.7.0.820357853432.issue4322@psf.upfronthosting.co.za>
New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:
I ran into a case where I modified the __name__ attribute of a function
and then didn't specify the right number of arguments, and I got a
TypeError that used the original function name, as demonstrated here:
>>> def foo(): pass
...
>>> foo.__name__ = 'bar'
>>> foo(1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: foo() takes no arguments (1 given)
I would have expected it to say "TypeError: bar() ...". I'm guessing
that the interpreter isn't using the __name__ attribute in this case.
----------
components: Library (Lib)
messages: 75853
nosy: erickt
severity: normal
status: open
title: function with modified __name__ uses original name when there's an arg error
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4322>
_______________________________________
From report at bugs.python.org Fri Nov 14 12:03:15 2008
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9?=)
Date: Fri, 14 Nov 2008 11:03:15 +0000
Subject: [New-bugs-announce] [issue4323] Wrong encoding in files saved from
IDLE (3.0rc2 on Windows)
In-Reply-To: <1226660595.21.0.207360549663.issue4323@psf.upfronthosting.co.za>
Message-ID: <1226660595.21.0.207360549663.issue4323@psf.upfronthosting.co.za>
New submission from Andr? <info at orlans-amo.be>:
When saving a source file with non-ascii characters from an IDLE window,
on Windows platform (XP and Server 2003 at least)
with locale English US
locale.getdefaultlocale()
('en_US', 'cp1252')
IDLE prompts in IOBinding.py with the message
"non Ascii found, yet no encoding declared, Add a line like # -*-
coding: cp1252 -*-"
If accepted, the file is saved with the wrong encoding.
Afterwards, it is read back by IDLE without any problem and it looks
good in the IDLE window.
However, if a string with non-ascii characters is sent to another
module (i.e. email MIMEText)
the string is wrong.
The same source would be rejected by python in terminal mode and by
IDLE on Linux.
----------
messages: 75855
nosy: andre
severity: normal
status: open
title: Wrong encoding in files saved from IDLE (3.0rc2 on Windows)
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4323>
_______________________________________
From report at bugs.python.org Fri Nov 14 14:28:31 2008
From: report at bugs.python.org (Kai Willadsen)
Date: Fri, 14 Nov 2008 13:28:31 +0000
Subject: [New-bugs-announce] [issue4324] locale documentation is inconsistent
In-Reply-To: <1226669311.11.0.409442120812.issue4324@psf.upfronthosting.co.za>
Message-ID: <1226669311.11.0.409442120812.issue4324@psf.upfronthosting.co.za>
New submission from Kai Willadsen <kai.willadsen at gmail.com>:
The documentation for locale.getlocale is not consistent with the
example given. The docs for getlocale([category]) say:
"category may be one of the LC_* values except LC_ALL."
but the example at the bottom of the documentation starts with:
>>> import locale
>>> loc = locale.getlocale(locale.LC_ALL) # get current locale
...
----------
assignee: georg.brandl
components: Documentation
messages: 75861
nosy: georg.brandl, kaiw
severity: normal
status: open
title: locale documentation is inconsistent
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4324>
_______________________________________
From report at bugs.python.org Fri Nov 14 16:40:14 2008
From: report at bugs.python.org (dreamlusion)
Date: Fri, 14 Nov 2008 15:40:14 +0000
Subject: [New-bugs-announce] [issue4325] Installer crash on cancel
installation.
In-Reply-To: <1226677214.08.0.98432240651.issue4325@psf.upfronthosting.co.za>
Message-ID: <1226677214.08.0.98432240651.issue4325@psf.upfronthosting.co.za>
New submission from dreamlusion <dreamlusion at gmail.com>:
Steps to reproduce:
1. Start the installer (python-2.6.msi)
2. Choose install for all users, next.
3. Select default directory, next.
4. Click "Advanced".
5. Click "Cancel" and confirm (click yes).
Bang.
----------
components: Installation
messages: 75865
nosy: dreamlusion
severity: normal
status: open
title: Installer crash on cancel installation.
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4325>
_______________________________________
From report at bugs.python.org Fri Nov 14 22:36:32 2008
From: report at bugs.python.org (chafporte)
Date: Fri, 14 Nov 2008 21:36:32 +0000
Subject: [New-bugs-announce] [issue4326] type of UserList instance returns
class instead of instance
In-Reply-To: <1226698592.14.0.169733177336.issue4326@psf.upfronthosting.co.za>
Message-ID: <1226698592.14.0.169733177336.issue4326@psf.upfronthosting.co.za>
New submission from chafporte <junk at ysengrin.com>:
from UserList import UserList
lu = UserList()
type(lu)
python2.6 prints: <class 'UserList.UserList'>
python2.5 prints: <type 'instance'>
----------
components: None
messages: 75885
nosy: chafporte
severity: normal
status: open
title: type of UserList instance returns class instead of instance
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4326>
_______________________________________
From report at bugs.python.org Fri Nov 14 22:47:39 2008
From: report at bugs.python.org (David Turner)
Date: Fri, 14 Nov 2008 21:47:39 +0000
Subject: [New-bugs-announce] [issue4327] Patch: simplify complex constant
assignment statements
In-Reply-To: <1226699259.32.0.049436327998.issue4327@psf.upfronthosting.co.za>
Message-ID: <1226699259.32.0.049436327998.issue4327@psf.upfronthosting.co.za>
New submission from David Turner <novalis at novalis.org>:
This patch adds functionality to the optimizer to simplify complex
constant assignments like:
a, (b, c) = d, e = 1, (2, 3)
The simplification is:
a = 1
d = 1
b, c = e = 2, 3
Of course, the simplified version is semantically identical. But the
bytecode generated is faster, because there is less need to unpack
tuples. Naturally, this only works on constants:
a, b = 1, a is not the same as
a = 1
b = a
----------
files: tlee-ast-optimize-multiassign.diff
keywords: patch
messages: 75889
nosy: novalis_dt
severity: normal
status: open
title: Patch: simplify complex constant assignment statements
Added file: http://bugs.python.org/file12012/tlee-ast-optimize-multiassign.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4327>
_______________________________________
From report at bugs.python.org Sat Nov 15 10:27:24 2008
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 15 Nov 2008 09:27:24 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlNDMyOF0gIsOgIiBpbiB1ImZv?=
=?utf-8?q?o=22_raises_a_misleading_error?=
In-Reply-To: <1226741244.61.0.833545368302.issue4328@psf.upfronthosting.co.za>
Message-ID: <1226741244.61.0.833545368302.issue4328@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
With Python 2.x:
>>> '?' in u'foo'
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: 'in <string>' requires string as left operand
>>> '?' in u'x?x'
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: 'in <string>' requires string as left operand
The error claims that "'in <string>' requires string as left operand"
when actually the left operand *is* a string.
With Python2.6 with unicode_literals:
>>> print(b'\x85')
?
>>> b'\x85' in 'foo'
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'in <string>' requires string as left operand
With Python3.x the error is slightly different:
TypeError: 'in <string>' requires string as left operand, not bytes
but then it works with:
>>> b'f' in 'foo'
True
This problem seems somehow related to the implicit decoding of '?'. I
guess that '?' in u'foo' should raise a UnicodeDecodeError ('xxx' codec
can't decode byte 0x85 ...), not a TypeError.
----------
components: Unicode
messages: 75907
nosy: ezio.melotti
severity: normal
status: open
title: "?" in u"foo" raises a misleading error
versions: Python 2.4, Python 2.5, Python 2.5.3, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4328>
_______________________________________
From report at bugs.python.org Sat Nov 15 12:11:25 2008
From: report at bugs.python.org (Michael Becker)
Date: Sat, 15 Nov 2008 11:11:25 +0000
Subject: [New-bugs-announce] [issue4329] base64 does not properly handle
unicode strings
In-Reply-To: <1226747485.51.0.230106735206.issue4329@psf.upfronthosting.co.za>
Message-ID: <1226747485.51.0.230106735206.issue4329@psf.upfronthosting.co.za>
New submission from Michael Becker <spammb at gmail.com>:
See below. unicode string causes exception. Explicitly converting it to
a regular string addresses the issue. I only noticed this because my
input string changed to unicode after updating python to 2.6 and django
to 1.0.
>>> import base64
>>>
a=u'aHR0cDovL3NvdXJjZWZvcmdlLm5ldC90cmFja2VyMi8_ZnVuYz1kZXRhaWwmYWlkPTIyNTg5MzUmZ3JvdXBfaWQ9MTI2OTQmYXRpZD0xMTI2OTQ='
>>> b=base64.urlsafe_b64decode(a)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python2.6/base64.py", line 112, in urlsafe_b64decode
return b64decode(s, '-_')
File "/usr/local/lib/python2.6/base64.py", line 71, in b64decode
s = _translate(s, {altchars[0]: '+', altchars[1]: '/'})
File "/usr/local/lib/python2.6/base64.py", line 36, in _translate
return s.translate(''.join(translation))
TypeError: character mapping must return integer, None or unicode
>>> b=base64.urlsafe_b64decode(str(a))
>>> b
'http://sourceforge.net/tracker2/?func=detail&aid=2258935&group_id=12694&atid=112694'
----------
components: Unicode
messages: 75911
nosy: mbecker
severity: normal
status: open
title: base64 does not properly handle unicode strings
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4329>
_______________________________________
From report at bugs.python.org Sun Nov 16 01:43:04 2008
From: report at bugs.python.org (Ian Bicking)
Date: Sun, 16 Nov 2008 00:43:04 +0000
Subject: [New-bugs-announce] [issue4330] wsgiref.validate doesn't accept
arguments to readline
In-Reply-To: <1226796184.02.0.689676088557.issue4330@psf.upfronthosting.co.za>
Message-ID: <1226796184.02.0.689676088557.issue4330@psf.upfronthosting.co.za>
New submission from Ian Bicking <ianb at colorstudy.com>:
The method wsgiref.validate:InputWrapper.readline doesn't take any
arguments. It should take an optional size argument. Though this isn't
part of the WSGI specification, the cgi module uses this argument when
parsing the body, and in practice no applications that use
cgi.FieldStorage (which is most applications) are compatible with
wsgiref.validate as a result. Simply adding a *args that is passed to
the underlying file fixes this.
----------
components: Library (Lib)
messages: 75920
nosy: ianb
severity: normal
status: open
title: wsgiref.validate doesn't accept arguments to readline
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4330>
_______________________________________
From report at bugs.python.org Sun Nov 16 07:33:00 2008
From: report at bugs.python.org (scott sadler)
Date: Sun, 16 Nov 2008 06:33:00 +0000
Subject: [New-bugs-announce] [issue4331] Can't use _functools.partial()
created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
New submission from scott sadler <ssadler at mashi.org>:
Calling a function created by _functools.partial as a method raises an
exception:
"TypeError: method_new() takes exactly n non-keyword arguments (0 given)"
Where method_new is the function passed into partial() and n is the
number of arguments it expects.
This does not happen when using a python version of partial().
Strangely, in the circumstance that I originally encountered the bug,
there was one instance that I was doing this and it _DID WORK_. The
function being passed into partial() was the same as in the place where
it was failing. The only significant difference that I could see was
that the input function to partial() was being imported, rather than
being defined in the same namespace as it was used I was unable to
reproduce it in my test case (attatched).
Tested on 2.6 and 2.5.2
----------
components: Extension Modules
files: partialbug.py
messages: 75928
nosy: ssadler
severity: normal
status: open
title: Can't use _functools.partial() created function as method
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file12017/partialbug.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4331>
_______________________________________
From report at bugs.python.org Mon Nov 17 01:20:32 2008
From: report at bugs.python.org (Christian Becke)
Date: Mon, 17 Nov 2008 00:20:32 +0000
Subject: [New-bugs-announce] [issue4332] asyncore.file_dispatcher does not
use dup()'ed fd
In-Reply-To: <1226881232.51.0.043979894828.issue4332@psf.upfronthosting.co.za>
Message-ID: <1226881232.51.0.043979894828.issue4332@psf.upfronthosting.co.za>
New submission from Christian Becke <christianbecke at gmail.com>:
asyncore.file_dispatcher stores the file descriptor passed to
asyncore.file_dispatcher.__init__ into the map, not the dup()'ed one
created by asyncore.file_wrapper. Because of this, a "select.error (9,
'Bad file descriptor')" is raised in asyncore.loop() if the fd passed to
asyncore.file_dispatcher.__init__ is closed while the loop is running.
Attached patch fixes the issue.
----------
components: Library (Lib)
files: asyncore_file_dispatcher_use_duped_fd.diff
keywords: patch
messages: 75947
nosy: christianbecke
severity: normal
status: open
title: asyncore.file_dispatcher does not use dup()'ed fd
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12022/asyncore_file_dispatcher_use_duped_fd.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4332>
_______________________________________
From report at bugs.python.org Mon Nov 17 01:23:24 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 17 Nov 2008 00:23:24 +0000
Subject: [New-bugs-announce] [issue4333] Reworked Dialog.py
In-Reply-To: <1226881404.91.0.533308530681.issue4333@psf.upfronthosting.co.za>
Message-ID: <1226881404.91.0.533308530681.issue4333@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Hi,
I have changed the lib-tk/Dialog.py so it handles the cases where one
might receive a tuple as a result containing a Tcl_Obj. I've also
modified all the rest of it to make it "cleaner".
It is b/w compatible although I dislike the usage of cnf, but I guess
I'm too late to suggest this change even for py3k :/
A "more complete" description of the changes is in
http://svn.python.org/view?rev=67240&view=rev
----------
components: Tkinter
files: Dialog.diff
keywords: patch
messages: 75948
nosy: gpolo
severity: normal
status: open
title: Reworked Dialog.py
versions: Python 2.7
Added file: http://bugs.python.org/file12023/Dialog.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4333>
_______________________________________
From report at bugs.python.org Mon Nov 17 01:25:24 2008
From: report at bugs.python.org (Noah Gift)
Date: Mon, 17 Nov 2008 00:25:24 +0000
Subject: [New-bugs-announce] [issue4334] Mac Build Script is broken for 2.6
release
In-Reply-To: <1226881524.11.0.708163109076.issue4334@psf.upfronthosting.co.za>
Message-ID: <1226881524.11.0.708163109076.issue4334@psf.upfronthosting.co.za>
New submission from Noah Gift <noah.gift at gmail.com>:
Just an FYI, the Mac Build script in:
Python-2.6 2/Mac/BuildScript/build-installer.py
contains broken download URLs for SQLite, and cause the build to fail.
I fixed this myself, but noticed this appears to be fixed in the trunk,
already. Having a working build script is a fairly big deal for mac
users, as they often need to have readline compiled properly with
Python, which is a pain. This might be nice to have fixed in the
production release.
----------
components: Build
messages: 75949
nosy: ngift
severity: normal
status: open
title: Mac Build Script is broken for 2.6 release
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4334>
_______________________________________
From report at bugs.python.org Mon Nov 17 09:09:11 2008
From: report at bugs.python.org (Rafe Sacks)
Date: Mon, 17 Nov 2008 08:09:11 +0000
Subject: [New-bugs-announce] [issue4335] inspect.getsourcelines ignores last
line in module
In-Reply-To: <1226909351.26.0.938399226191.issue4335@psf.upfronthosting.co.za>
Message-ID: <1226909351.26.0.938399226191.issue4335@psf.upfronthosting.co.za>
New submission from Rafe Sacks <rafesacks at gmail.com>:
Hi,
If the last line of the function is also the last line of the module, it
is ignored. To repro:
1) Create module 'repro'
<module>
def test():
module_line_2 = None
module_line_3 = None
module_line_4 = None
module_line_5 = None
<end module>
2) Run test:
>>> import repro
>>> import inspect
>>> inspect.getsourcelines(tmp.test)
(['def test():\n', ' module_line_2 = None\n', ' module_line_3 =
None\n', ' module_line_4 = None\n'], 1)
notice no module_line_5.
cheers,
- Rafe
----------
components: Library (Lib)
messages: 75953
nosy: RafeSacks
severity: normal
status: open
title: inspect.getsourcelines ignores last line in module
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4335>
_______________________________________
From report at bugs.python.org Mon Nov 17 15:33:41 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 17 Nov 2008 14:33:41 +0000
Subject: [New-bugs-announce] [issue4336] Fix performance issues in xmlrpclib
In-Reply-To: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>
Message-ID: <1226932421.11.0.872911909056.issue4336@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
There are two performance problems in xmlrpclib.py:
POST requests use two send() calls, one to send the headers and one to
send the data. This can invoke the Nagle/Delayed ACK performance
problem. On many socket implementations (including some windows
platforms) it can introduce delays of up to 200ms when talking over the
wire (as opposed to localhost)
The second is the use of no buffering when reading the xmlrpc
response. It is done using the readline() call on a file-like object
constructed from the socket. When no buffering is in effect, this
causes a separate recv() call for each character.
This patch fixes these issues separately:
1) We provide a new getheaderdata() function in httplib which just
returns the data for the headers instead of sending it. This can be
used instead of endheaders() if the intention is to subsequently send
more data. xmlrpclib then uses this method of framing its POST
messages.
2) We provide the named artgument bufsize=0 to the HTTPResponse class
in httplib, and also so on for the HTTPConnection.getresponse() and
HTTP.getreply(). xmlrpclib then passes bufsize=-1 to HTTP.getreply() to
get default buffering for the response fileobject.
This patch focuses on fixing the problems with xmlrpclib. but issue 1)
above also has a number of other manifestations in the lib, there are
other places where we can use getheaderdata() and send() instead of
endheaders() to avoid possible Nagle/Ack problems, e.g. in urllib.py,
distutils.py and loggin/handlers.py
----------
components: Extension Modules
files: xmlrpc.patch
keywords: easy, patch, patch
messages: 75962
nosy: krisvale
severity: normal
status: open
title: Fix performance issues in xmlrpclib
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file12030/xmlrpc.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4336>
_______________________________________
From report at bugs.python.org Mon Nov 17 16:54:36 2008
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Mon, 17 Nov 2008 15:54:36 +0000
Subject: [New-bugs-announce] [issue4337] Iteration over a map object with
list()
In-Reply-To: <1226937276.11.0.323552231555.issue4337@psf.upfronthosting.co.za>
Message-ID: <1226937276.11.0.323552231555.issue4337@psf.upfronthosting.co.za>
New submission from Jean-Michel Fauth <wxjmfauth at gmail.com>:
win XP sp2, Py3.0c2
I had to face an annoying problem when iterating over a map object.
With a range class, this works
>>> r = range(5)
>>> list(r)
[0, 1, 2, 3, 4]
With dict_keys/values/items objects, the following works
>>> d = {1: 'a', 2:'b', 3:'c'}
>>> list(d.keys())
[1, 2, 3]
>>> list(d.values())
['a', 'b', 'c']
>>> list(d.items())
[(1, 'a'), (2, 'b'), (3, 'c')]
But with a map object...
>>> def plus(i):
return i + 1
>>> a = list(range(3))
>>> a
[0, 1, 2]
>>> r = map(plus, a)
>>> r
<map object at 0x01371570>
>>> for e in r: print(e)
1
2
3
>>> list(r)
[]
>>> #empty list!
Bug or feature?
----------
components: None
messages: 75965
nosy: jmfauth
severity: normal
status: open
title: Iteration over a map object with list()
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4337>
_______________________________________
From report at bugs.python.org Mon Nov 17 18:40:10 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 17 Nov 2008 17:40:10 +0000
Subject: [New-bugs-announce] [issue4338] TypeError (bytes/str) in distutils
command "upload"
In-Reply-To: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za>
Message-ID: <1226943610.63.0.394429375639.issue4338@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
"python3.0 setup.py upload" (on an otherwise sane setup script) results
in the following:
Traceback (most recent call last):
File "setup.py", line 5, in <module>
import py3setup
File "/home/MP/hagenf/src/pyskein/py3setup.py", line 22, in <module>
ext_modules=[ext])
File "/home/MP/hagenf/local/lib/python3.0/distutils/core.py", line
149, in setup
dist.run_commands()
File "/home/MP/hagenf/local/lib/python3.0/distutils/dist.py", line
942, in run_commands
self.run_command(cmd)
File "/home/MP/hagenf/local/lib/python3.0/distutils/dist.py", line
962, in run_command
cmd_obj.run()
File
"/home/MP/hagenf/local/lib/python3.0/distutils/command/upload.py", line
55, in run
self.upload_file(command, pyversion, filename)
File
"/home/MP/hagenf/local/lib/python3.0/distutils/command/upload.py", line
116, in upload_file
auth = "Basic " + base64.encodestring(self.username + ":" +
self.password).strip()
File "/home/MP/hagenf/local/lib/python3.0/base64.py", line 338, in
encodestring
raise TypeError("expected bytes, not %s" % s.__class__.__name__)
TypeError: expected bytes, not str
----------
components: Distutils
messages: 75975
nosy: hagen
severity: normal
status: open
title: TypeError (bytes/str) in distutils command "upload"
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4338>
_______________________________________
From report at bugs.python.org Mon Nov 17 21:14:19 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Nov 2008 20:14:19 +0000
Subject: [New-bugs-announce] [issue4339] Fix set-like dictview doc
In-Reply-To: <1226952859.0.0.283857665516.issue4339@psf.upfronthosting.co.za>
Message-ID: <1226952859.0.0.283857665516.issue4339@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
I see two problems with the current (.rc2) doc on "Dictionary view
objects" that are set-like.
1. The first paragraph of the section ends with the fragment
"The keys and items views have a set-like character since their entries"
This is not only incomplete, but wrong. Items views are set-like
(entries are unique and hashable) only if all values are hashable, as
revealed way at the end in a 'warning' that is only needed because of
the previous over-generalization. I recommend that this fragment, the
one sentence after the 'x in dictview' entry, and the warning be
combined into one paragraph that tells the complete story at the
appropriate place, which is where the 'one sentence' is now.
"Keys views are set-like since their entries are unique and hashable.
If all values are hashable, so that (key,value) pairs are unique and
hashable, then an items view is also set-like. (Values views are not
treated as set-like since the entries are generally not unique.) Let
'set-view' and 'other' each be a set or set-like view. Then the
following set operations are available."
This suggestion also addresses the second problem I see. The set
operations are symmetric, but 'dictview op other' is not. It excludes
the valid combination 'set op dictview'. So I think all 4 ops should be
listed as 'set-view op other' instead, after the revised introduction above.
----------
assignee: georg.brandl
components: Documentation
messages: 75979
nosy: georg.brandl, tjreedy
severity: normal
stage: needs patch
status: open
title: Fix set-like dictview doc
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4339>
_______________________________________
From report at bugs.python.org Mon Nov 17 21:55:59 2008
From: report at bugs.python.org (Mike Watkins)
Date: Mon, 17 Nov 2008 20:55:59 +0000
Subject: [New-bugs-announce] [issue4340] xmlrpc.client - default
'SlowParser' not defined
In-Reply-To: <1226955359.62.0.344103118813.issue4340@psf.upfronthosting.co.za>
Message-ID: <1226955359.62.0.344103118813.issue4340@psf.upfronthosting.co.za>
New submission from Mike Watkins <python at mikewatkins.ca>:
Running example code from docs:
http://docs.python.org/dev/3.0/library/xmlrpc.client.html#example-of-
client-usage
z% python
Python 3.0rc2+ (py3k:67152, Nov 7 2008, 16:48:55)
[GCC 4.2.1 20070719 [FreeBSD]] on freebsd7
Type "help", "copyright", "credits" or "license" for more information.
>>> str(None)
'None'
>>> from xmlrpc.client import ServerProxy, Error
>>> server = ServerProxy("http://betty.userland.com")
>>> print(server)
<ServerProxy for betty.userland.com/RPC2>
>>> print(server)
<ServerProxy for betty.userland.com/RPC2>
>>> print(server.examples.getStateName(41))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1095, in
__call__
return self.__send(self.__name, args)
File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1353, in
__request
verbose=self.__verbose
File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1136, in
request
return self._parse_response(resp, None)
File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1235, in
_parse_response
p, u = self.getparser()
File "/usr/local/lib/python3.0/xmlrpc/client.py", line 1145, in
getparser
return getparser(use_datetime=self._use_datetime)
File "/usr/local/lib/python3.0/xmlrpc/client.py", line 975, in
getparser
parser = SlowParser(target)
NameError: global name 'SlowParser' is not defined
No definition of SlowParser in client.py:
/src/py3k/Lib/xmlrpc% grep -n SlowParser client.py
116: SlowParser Slow but safe standard parser (based on xmllib)
975: parser = SlowParser(target)
----------
components: Library (Lib)
messages: 75980
nosy: mwatkins
severity: normal
status: open
title: xmlrpc.client - default 'SlowParser' not defined
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4340>
_______________________________________
From report at bugs.python.org Mon Nov 17 22:48:35 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Nov 2008 21:48:35 +0000
Subject: [New-bugs-announce] [issue4341] Update __hash__ doc
In-Reply-To: <1226958515.3.0.535002715337.issue4341@psf.upfronthosting.co.za>
Message-ID: <1226958515.3.0.535002715337.issue4341@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
Language/data model/special method names/ __hash__
Sentence 1: "Called for the key object for dictionary operations, and by
the built-in function hash()."
Also called for the members of set and frozenset (and any other hashed
based collection).
Suggestion 1: "Called by the built-in function hash() and for operations
on members or keys of hashed collections. These currently include the
built-in classes set, frozenset, and dict."
Corresponding future-proof changes later in the text:
>From "its instances will not be usable as dictionary keys"
to "its instances will not be usable as hashable members or keys".
>From "since the dictionary implementation requires"
to "since hashable collection implementations require"
==============================
Sentence 2: "Should return an integer usable as a hash value for
dictionary operations."
I am confused by the qualification 'usable....'. If it does not
qualify, it is meaningless and should be removed. If it does qualify,
it should be replaced by what it means.
My impression is that integers of any value are usable since 2.5.
It is also my impression that 2.x specifically requires an int or long.
If so, "Should return an int or long integer." would be clearer.
For 3.0, I don't know what the boundaries are. A float works, even if
not integral. [bug?] A Fraction does not, even if integral, even though
int(Fraction(n,1)) returns n.
----------
assignee: georg.brandl
components: Documentation
messages: 75984
nosy: georg.brandl, tjreedy
severity: normal
stage: needs patch
status: open
title: Update __hash__ doc
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4341>
_______________________________________
From report at bugs.python.org Tue Nov 18 01:41:32 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Nov 2008 00:41:32 +0000
Subject: [New-bugs-announce] [issue4342] (Tkinter) Please backport these
In-Reply-To: <1226968892.91.0.114807177432.issue4342@psf.upfronthosting.co.za>
Message-ID: <1226968892.91.0.114807177432.issue4342@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Please consider backporting r59653 and r59654 to release25-maint branch.
It may be of interest to backport r52688 too, also, r63776 together with
r63914 (without these last two I get segfault when passing a list as an
option value).
Finally there is this issue4333 which wasn't committed anywhere, but if
it gets committed I would like to see it getting backported too.
Thanks.
----------
components: Tkinter
messages: 75995
nosy: gpolo
severity: normal
status: open
title: (Tkinter) Please backport these
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4342>
_______________________________________
From report at bugs.python.org Tue Nov 18 13:39:19 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Nov 2008 12:39:19 +0000
Subject: [New-bugs-announce] [issue4343] New function in Tkinter.py:
setup_master
In-Reply-To: <1227011959.0.0.968897886388.issue4343@psf.upfronthosting.co.za>
Message-ID: <1227011959.0.0.968897886388.issue4343@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Hi,
I've added a new function called setup_master.
This function is responsible for returning an usable master to the
caller, or fail and say so. The function is useful for any wrapper
basically, since all them has to set up a master sometime (or maybe
always require a master, but that is not very nice) and will usually do
it half wrong. The half wrong is about relying on _default_root being
available in Tkinter, which is not the case if support for default root
has been disabled.
There are two patches, the first adds the function, the second applies
it self where necessary in Tkinter. The later also adds some new
behaviour in Tkinter, previously Variable class and subclasses wouldn't
work properly without prior creation of a master (there are similar
problems in other parts too).
----------
components: Tkinter
files: setup_master.diff
keywords: patch
messages: 76005
nosy: gpolo
severity: normal
status: open
title: New function in Tkinter.py: setup_master
versions: Python 2.7, Python 3.0
Added file: http://bugs.python.org/file12040/setup_master.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4343>
_______________________________________
From report at bugs.python.org Tue Nov 18 13:49:41 2008
From: report at bugs.python.org (kasper)
Date: Tue, 18 Nov 2008 12:49:41 +0000
Subject: [New-bugs-announce] [issue4344] crash upon launch
In-Reply-To: <1227012581.68.0.953294205264.issue4344@psf.upfronthosting.co.za>
Message-ID: <1227012581.68.0.953294205264.issue4344@psf.upfronthosting.co.za>
New submission from kasper <kr_900 at hotmail.com>:
Hi
I'm new at programming and have chosen to start with python, and so I
have installed python 2.6, and played around with it a little.
However, a problem has occured: yesterday when i tried to run the
program - pythonwin editor 2.6.0 - a crash occured immediately upon
launch. All i do is start up the program, and while trying to open, the
program crashes, and a windows error window pops up, telling me that
'the program has encountered an error, and will now exit' - not telling
me anything useful about what kind of error has occured, or why. As
usual, the windows errorreport is of no use. And so I have little idea
of what causes the crash, but I do have a suspicion that the .dll
mfc90.dll might be a part of the problem, since it is mentioned in the
beginning of the errorreport.
Looking forward to hear from you.
Kasper
----------
components: Windows
messages: 76006
nosy: source.mod
severity: normal
status: open
title: crash upon launch
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4344>
_______________________________________
From report at bugs.python.org Tue Nov 18 15:01:15 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Nov 2008 14:01:15 +0000
Subject: [New-bugs-announce] [issue4345] Implement nb_nonzero for PyTclObject
In-Reply-To: <1227016875.57.0.463307209634.issue4345@psf.upfronthosting.co.za>
Message-ID: <1227016875.57.0.463307209634.issue4345@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Implementing it makes this "crazy" check in
http://bugs.python.org/issue3767
(http://bugs.python.org/file12043/tkColorChooser.diff) be no longer needed
----------
components: Tkinter
files: _tkinter__nonzero__.diff
keywords: patch
messages: 76008
nosy: gpolo
severity: normal
status: open
title: Implement nb_nonzero for PyTclObject
versions: Python 2.6, Python 2.7, Python 3.0
Added file: http://bugs.python.org/file12044/_tkinter__nonzero__.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4345>
_______________________________________
From report at bugs.python.org Tue Nov 18 15:15:20 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Nov 2008 14:15:20 +0000
Subject: [New-bugs-announce] [issue4346] PyObject_CallMethod changes the
exception message already set by PyObject_GetAttr
In-Reply-To: <1227017720.01.0.112991590053.issue4346@psf.upfronthosting.co.za>
Message-ID: <1227017720.01.0.112991590053.issue4346@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
Why is PyObject_CallMethod resetting the exception message that is
already set (if an exception happened, that is) by PyObject_Getattr ?
----------
components: Interpreter Core
files: abstract_dont_re_set_except_msg.diff
keywords: patch
messages: 76009
nosy: gpolo
severity: normal
status: open
title: PyObject_CallMethod changes the exception message already set by PyObject_GetAttr
versions: Python 2.7
Added file: http://bugs.python.org/file12045/abstract_dont_re_set_except_msg.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4346>
_______________________________________
From report at bugs.python.org Tue Nov 18 16:28:11 2008
From: report at bugs.python.org (Thomas Lee)
Date: Tue, 18 Nov 2008 15:28:11 +0000
Subject: [New-bugs-announce] [issue4347] Dependencies of graminit.h are not
rebuilt when the file is regenerated
In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za>
Message-ID: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za>
New submission from Thomas Lee <tom at vector-seven.com>:
It's important that dependencies of grammar.h get rebuilt if graminit.h
is regenerated (e.g. the Grammar is modified). If these dependencies do
not get rebuilt, the constants associated with each type of parse node
will have inconsistent values between the different intermediate files.
The net result is that a program afflicted by this might build without
errors, but then crash unexpectedly at runtime due to the inconsistent
constant values.
The patch is quite simple and ensures that all files that currently
depend on graminit.h are rebuilt if it changes.
It also removes an unnecessary #include from Python/future.c.
I believe a similar situation might occur with Python-ast.h and the
*_kind enumerations, but have yet to run into such a specific issue.
I'll post a separate patch if I do find this to be a problem.
----------
components: Build
files: graminit-dependencies.patch
keywords: patch
messages: 76010
nosy: thomas.lee
severity: normal
status: open
title: Dependencies of graminit.h are not rebuilt when the file is regenerated
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12046/graminit-dependencies.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4347>
_______________________________________
From report at bugs.python.org Tue Nov 18 22:29:15 2008
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 18 Nov 2008 21:29:15 +0000
Subject: [New-bugs-announce] [issue4348] bytearray methods returning self
In-Reply-To: <1227043755.26.0.890886477105.issue4348@psf.upfronthosting.co.za>
Message-ID: <1227043755.26.0.890886477105.issue4348@psf.upfronthosting.co.za>
New submission from Dino Viehland <dinov at microsoft.com>:
In 2.6 but not in 3.0 RC2:
x = bytearray(b'abc')
y = x.replace(b'abc', b'bar', 0)
id(x) == id(y)
In 2.6 and in 3.0 RC2:
t = bytearray()
for i in range(256): t.append(i)
x = bytearray(b'')
y = x.translate(t)
id(x) == id(y)
----------
messages: 76012
nosy: DinoV
severity: normal
status: open
title: bytearray methods returning self
type: behavior
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4348>
_______________________________________
From report at bugs.python.org Tue Nov 18 22:36:32 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 18 Nov 2008 21:36:32 +0000
Subject: [New-bugs-announce] [issue4349] sys.path includes extraneous junk
In-Reply-To: <1227044192.68.0.160920298977.issue4349@psf.upfronthosting.co.za>
Message-ID: <1227044192.68.0.160920298977.issue4349@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
With a recent build of the py3k branch, sys.path ends up with this element:
/home/exarkun/Projects/python/branches/py3k/Lib/plat-linux2 at EXTRAMACHDEPPATH@
which doesn't exist and doesn't look like it should exist. plat-linux2,
which does exist, doesn't end up winth sys.path.
----------
components: Interpreter Core
messages: 76013
nosy: exarkun
severity: normal
status: open
title: sys.path includes extraneous junk
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4349>
_______________________________________
From report at bugs.python.org Wed Nov 19 01:14:19 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 19 Nov 2008 00:14:19 +0000
Subject: [New-bugs-announce] [issue4350] Remove dead code from Tkinter.py
In-Reply-To: <1227053659.32.0.711141995765.issue4350@psf.upfronthosting.co.za>
Message-ID: <1227053659.32.0.711141995765.issue4350@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
There are some methods (which call tk commands) that no longer exist,
for a long time now so this patch remove them.
There are also these "indices" functions, which do not belong to the
module space and now are gone too.
----------
files: remove_dead_code.diff
keywords: patch
messages: 76030
nosy: gpolo
severity: normal
status: open
title: Remove dead code from Tkinter.py
versions: Python 2.7, Python 3.0
Added file: http://bugs.python.org/file12050/remove_dead_code.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4350>
_______________________________________
From report at bugs.python.org Wed Nov 19 01:22:34 2008
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 19 Nov 2008 00:22:34 +0000
Subject: [New-bugs-announce] [issue4351] [PATCH] Better stacklevel for
GzipFile.filename DeprecationWarning
In-Reply-To: <1227054154.01.0.966318023814.issue4351@psf.upfronthosting.co.za>
Message-ID: <1227054154.01.0.966318023814.issue4351@psf.upfronthosting.co.za>
New submission from Philip Jenvey <pjenvey at users.sourceforge.net>:
This should be a stacklevel of 2 so we're told who accessed the attribute
----------
components: Library (Lib)
files: gzip-deprecation_r67276.diff
keywords: patch
messages: 76031
nosy: pjenvey
severity: normal
status: open
title: [PATCH] Better stacklevel for GzipFile.filename DeprecationWarning
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12051/gzip-deprecation_r67276.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4351>
_______________________________________
From report at bugs.python.org Wed Nov 19 06:17:46 2008
From: report at bugs.python.org (Jukka Aho)
Date: Wed, 19 Nov 2008 05:17:46 +0000
Subject: [New-bugs-announce] [issue4352] imp.find_module() causes
UnicodeDecodeError with non-ASCII search paths
In-Reply-To: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za>
Message-ID: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za>
New submission from Jukka Aho <jukka.aho at iki.fi>:
imp.find_module() seems to cause an UnicodeDecodeError when the path
list contains paths with non-ASCII names. Tested on Windows [1]; see the
attached test case which demonstrates the problem.
[1] Python 3.0rc2 (r30rc2:67141, Nov 7 2008, 11:43:46) [MSC v.1500 32
bit (Intel)] on win32
----------
components: Library (Lib), Unicode, Windows
files: find_module.py
messages: 76038
nosy: Jukka Aho
severity: normal
status: open
title: imp.find_module() causes UnicodeDecodeError with non-ASCII search paths
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12055/find_module.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4352>
_______________________________________
From report at bugs.python.org Wed Nov 19 16:34:27 2008
From: report at bugs.python.org (rocky bernstein)
Date: Wed, 19 Nov 2008 15:34:27 +0000
Subject: [New-bugs-announce] [issue4353] Move description what a trace
should should return to settrace from pdb section into
sys.settrace section
In-Reply-To: <1227108867.52.0.266510859122.issue4353@psf.upfronthosting.co.za>
Message-ID: <1227108867.52.0.266510859122.issue4353@psf.upfronthosting.co.za>
New submission from rocky bernstein <rocky at gnu.org>:
This sentence:
The local trace function should return a reference to itself (or to
another function for further tracing in that scope), or None to turn off
tracing in that scope.
which appears under "How it [the debugger] Works" (http://docs.python.org
http://docs.python.org/library/pdb.html#debugger-hooks) should appear
under the description of (sys.settrace
http://docs.python.org/library/sys.html) since this really part of the
settrace interface and is not limited to the python debugger, pdb, or
debuggers in general.
----------
assignee: georg.brandl
components: Documentation
messages: 76051
nosy: georg.brandl, rocky
severity: normal
status: open
title: Move description what a trace should should return to settrace from pdb section into sys.settrace section
type: crash
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.5.3, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4353>
_______________________________________
From report at bugs.python.org Wed Nov 19 17:11:58 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 19 Nov 2008 16:11:58 +0000
Subject: [New-bugs-announce] [issue4354] distutils.command.register is broken
In-Reply-To: <1227111118.93.0.747245959239.issue4354@psf.upfronthosting.co.za>
Message-ID: <1227111118.93.0.747245959239.issue4354@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
The distutils command "register" has two problems with Python 3.0:
1. The authentication dialog crashes because of a problem with the
functiopn raw_input defined there.
2. Uploading the data fails because of str/bytes confusion.
The attached patch addresses both problems.
----------
components: Distutils
files: distutils_register.patch
keywords: patch
messages: 76055
nosy: hagen
severity: normal
status: open
title: distutils.command.register is broken
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12058/distutils_register.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4354>
_______________________________________
From report at bugs.python.org Wed Nov 19 17:19:54 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 19 Nov 2008 16:19:54 +0000
Subject: [New-bugs-announce] [issue4355] Error in docs of urllib.request and
urllib.parse
In-Reply-To: <1227111594.24.0.921624476893.issue4355@psf.upfronthosting.co.za>
Message-ID: <1227111594.24.0.921624476893.issue4355@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
The docs refer to urllib.urlencode instead of urllib.parse.urlencode. A
patch is attached.
----------
assignee: georg.brandl
components: Documentation
files: doc_urlencode.patch
keywords: patch
messages: 76056
nosy: georg.brandl, hagen
severity: normal
status: open
title: Error in docs of urllib.request and urllib.parse
versions: Python 3.0
Added file: http://bugs.python.org/file12059/doc_urlencode.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4355>
_______________________________________
From report at bugs.python.org Wed Nov 19 18:17:28 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Wed, 19 Nov 2008 17:17:28 +0000
Subject: [New-bugs-announce] [issue4356] Add "key" argument to "bisect"
module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
New submission from Miki Tebeka <miki.tebeka at gmail.com>:
It'd be helpful of the functions in the "bisect" modules will have a
"key" argument just like "sort".
----------
messages: 76060
nosy: tebeka
severity: normal
status: open
title: Add "key" argument to "bisect" module functions
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4356>
_______________________________________
From report at bugs.python.org Wed Nov 19 18:41:28 2008
From: report at bugs.python.org (Alex Samuel)
Date: Wed, 19 Nov 2008 17:41:28 +0000
Subject: [New-bugs-announce] [issue4357] frozen?set operations create
incorrectly initialized instances of subclasses
In-Reply-To: <1227116488.66.0.564572723144.issue4357@psf.upfronthosting.co.za>
Message-ID: <1227116488.66.0.564572723144.issue4357@psf.upfronthosting.co.za>
New submission from Alex Samuel <alex at alexsamuel.net>:
Methods of set and frozenset that return new set or frozenset instances
return instances of subclasses, but these instances are not initialized
correctly. In the attached code sample, z is an instance of MySet but
MySet.__new__ and MySet.__init__ are never called on it.
It seems to me that such a method should return a fully-initialized
instance of the subclass. Barring that, it should just return a set or
frozenset instance, not an instance of the subclass.
----------
assignee: theller
components: ctypes
files: fs.py
messages: 76062
nosy: alexhsamuel, theller
severity: normal
status: open
title: frozen?set operations create incorrectly initialized instances of subclasses
type: behavior
versions: Python 2.5, Python 3.0
Added file: http://bugs.python.org/file12062/fs.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4357>
_______________________________________
From report at bugs.python.org Wed Nov 19 19:34:30 2008
From: report at bugs.python.org (Farshad Khoshkhui)
Date: Wed, 19 Nov 2008 18:34:30 +0000
Subject: [New-bugs-announce] [issue4358] Segfault in stringobject.c
In-Reply-To: <1227119670.36.0.570140280059.issue4358@psf.upfronthosting.co.za>
Message-ID: <1227119670.36.0.570140280059.issue4358@psf.upfronthosting.co.za>
New submission from Farshad Khoshkhui <farshadkh at gmail.com>:
I'm encountering random segfaults on multiple machines. By examining
core dumps, it's all happening in stringobject.c (_PyString_Resize or
string_join).
By using pyframev I figured out it's always happening inside
xmlrpclib.py (/usr/lib/python2.5/xmlrpclib.py (716): dump_struct or
/usr/lib/python2.5/xmlrpclib.py (627): dumps)
I'm using Python 2.5.2 on debian in a threaded environment with heavy
use of xmlrpc.
----------
assignee: theller
components: XML, ctypes
files: backtrace1
messages: 76066
nosy: farshad, theller
severity: normal
status: open
title: Segfault in stringobject.c
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file12063/backtrace1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4358>
_______________________________________
From report at bugs.python.org Thu Nov 20 00:52:17 2008
From: report at bugs.python.org (Toshio Kuratomi)
Date: Wed, 19 Nov 2008 23:52:17 +0000
Subject: [New-bugs-announce] [issue4359] at runtime,
distutils uses buildtime files
In-Reply-To: <1227138737.98.0.796971482315.issue4359@psf.upfronthosting.co.za>
Message-ID: <1227138737.98.0.796971482315.issue4359@psf.upfronthosting.co.za>
New submission from Toshio Kuratomi <a.badger at gmail.com>:
When using some distutils functions, distutils attempts to use buildtime
files like Makefile and pyconfig*.h as data sources. For instance, this
snippet::
from distutils.command.install import install
from distutils.core import Distribution
dist = Distribution({"name": "foopkg"})
cmd = install(dist)
cmd.ensure_finalized()
There's two reasons this should change.
1) Some Linux distributions separate the python runtime and buildtime
files and put the buildtime files in a -devel package. Depending on
these buildtime files means that the -devel package can be needed for
running python scripts. For instance, here's the traceback that occurs
when the previous commands are run without python-devel on Fedora Linux::
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/distutils/cmd.py", line 117, in
ensure_finalized
self.finalize_options()
File "/usr/lib/python2.5/distutils/command/install.py", line 273, in
finalize_options
(prefix, exec_prefix) = get_config_vars('prefix', 'exec_prefix')
File "/usr/lib/python2.5/distutils/sysconfig.py", line 493, in
get_config_vars
func()
File "/usr/lib/python2.5/distutils/sysconfig.py", line 352, in
_init_posix
raise DistutilsPlatformError(my_msg)
distutils.errors.DistutilsPlatformError: invalid Python installation:
unable to open /usr/lib/python2.5/config/Makefile (No such file or
directory)
2) keeping the information in a Makefile and *.h files and then having
regular expressions pull the information out is fragile and not what the
tools were meant for. Using a defined data format is much better.
The variables necessary for building extensions should be placed in a
data file of some sort. This can be built by the configure script at
the same time as it's substituting variables into the Makefile and
pyconfig files.
xml is good for interoperability and we have good modules in the std
library for that now. .ini is less verbose and we have modules to deal
with that as well.
----------
components: Distutils
messages: 76083
nosy: a.badger
severity: normal
status: open
title: at runtime, distutils uses buildtime files
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4359>
_______________________________________
From report at bugs.python.org Thu Nov 20 11:29:20 2008
From: report at bugs.python.org (kai zhu)
Date: Thu, 20 Nov 2008 10:29:20 +0000
Subject: [New-bugs-announce] [issue4360] SystemError when method has both
super() & closure
In-Reply-To: <1227176960.74.0.918534699336.issue4360@psf.upfronthosting.co.za>
Message-ID: <1227176960.74.0.918534699336.issue4360@psf.upfronthosting.co.za>
New submission from kai zhu <davidbranniganz at gmail.com>:
################################
# super_closure.py
class A(object):
def foo(self):
return super()
# remove the closure below
# & SystemError goes away ???
lambda: self
A().foo()
################################
when run on 3.0rc1 & 3.0rc2:
hpc-login2 3 ~/work/py3to2: python3.0 super_closure.py
Traceback (most recent call last):
File "super_closure.py", line 9, in <module>
A().foo()
File "super_closure.py", line 5, in foo
return super()
SystemError: super(): __class__ is not a type (A)
SystemError seems to b raised from typeobject.c (line6155):
static int
super_init(PyObject *self, PyObject *args, PyObject *kwds)
{...
if (!PyType_Check(type)) {
PyErr_Format(PyExc_SystemError,
"super(): __class__ is not a type (%s)",
Py_TYPE(type)->tp_name);
return -1;
}
break;
----------
components: Build, Interpreter Core
messages: 76093
nosy: kaizhu
severity: normal
status: open
title: SystemError when method has both super() & closure
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4360>
_______________________________________
From report at bugs.python.org Thu Nov 20 13:42:48 2008
From: report at bugs.python.org (thp)
Date: Thu, 20 Nov 2008 12:42:48 +0000
Subject: [New-bugs-announce] [issue4361] Docstring for "Lib/string.py" is
outdated
In-Reply-To: <1227184968.64.0.811041606953.issue4361@psf.upfronthosting.co.za>
Message-ID: <1227184968.64.0.811041606953.issue4361@psf.upfronthosting.co.za>
New submission from thp <thp at thpinfo.com>:
The docstring in "Lib/string.py" in the source of "Python 3.0rc2" is
wrong. It currently says "lowercase", "uppercase" and "letters" where it
should say "ascii_lowercase", "ascii_uppercase" and "ascii_letters".
----------
assignee: georg.brandl
components: Documentation
files: Lib_string_py-docstring.patch
keywords: patch
messages: 76097
nosy: georg.brandl, thp
severity: normal
status: open
title: Docstring for "Lib/string.py" is outdated
versions: Python 3.0
Added file: http://bugs.python.org/file12069/Lib_string_py-docstring.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4361>
_______________________________________
From report at bugs.python.org Thu Nov 20 14:18:28 2008
From: report at bugs.python.org (David M. Beazley)
Date: Thu, 20 Nov 2008 13:18:28 +0000
Subject: [New-bugs-announce] [issue4362] FileIO object in io module
In-Reply-To: <1227187108.35.0.631350852787.issue4362@psf.upfronthosting.co.za>
Message-ID: <1227187108.35.0.631350852787.issue4362@psf.upfronthosting.co.za>
New submission from David M. Beazley <beazley at users.sourceforge.net>:
The FileIO object defined in the new io library has "name" and "mode"
properties. However, attempts to access either value result in an
AttributeError exception. The C source code in _fileio.c doesn't even
implement a name attribute and it uses a different name for mode ("mode"
instead of "_mode" that the property is looking for).
Broken in 2.6 and 3.0rc2.
----------
components: Library (Lib)
messages: 76100
nosy: beazley
severity: normal
status: open
title: FileIO object in io module
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4362>
_______________________________________
From report at bugs.python.org Thu Nov 20 15:44:28 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Thu, 20 Nov 2008 14:44:28 +0000
Subject: [New-bugs-announce] [issue4363] Make uuid module functions usable
without ctypes
In-Reply-To: <1227192268.71.0.69220527161.issue4363@psf.upfronthosting.co.za>
Message-ID: <1227192268.71.0.69220527161.issue4363@psf.upfronthosting.co.za>
New submission from Dmitry Vasiliev <dima at hlabs.spb.ru>:
The attached patch removes dependency on ctypes from uuid.uuid1() and
uuid.uuid4() functions.
----------
components: Library (Lib)
files: uuid.patch
keywords: patch
messages: 76107
nosy: hdima
severity: normal
status: open
title: Make uuid module functions usable without ctypes
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12071/uuid.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4363>
_______________________________________
From report at bugs.python.org Thu Nov 20 16:19:26 2008
From: report at bugs.python.org (Brian D'Urso)
Date: Thu, 20 Nov 2008 15:19:26 +0000
Subject: [New-bugs-announce] [issue4364] error in multiprocessing docs -
rawvalue
In-Reply-To: <1227194366.84.0.640745575496.issue4364@psf.upfronthosting.co.za>
Message-ID: <1227194366.84.0.640745575496.issue4364@psf.upfronthosting.co.za>
New submission from Brian D'Urso <dursobr at pitt.edu>:
There is an error in the multiprocessing package documentation:
In the sentence:
'Note that an array of ctypes.c_char has value and rawvalue attributes
which allow one to use it to store and retrieve strings.'
The error is that 'rawvalue' should be 'raw'.
This sentence actually occurs in two places: under multiprocessing.Array
and just before multiprocessing.sharedctypes.Array. It looks to me like
the second occurrence of the sentence is in the wrong place - I think it
should be in the multiprocessing.sharedctypes.Array section instead of
just before it.
To see that the attribute name is 'raw', just do:
>>> import ctypes, multiprocessing
>>> dir(multiprocessing.Array(ctypes.c_char, 1))
==> ['__class__', '__delattr__', '__dict__', '__doc__', '__format__',
'__getattribute__', '__getitem__', '__getslice__', '__hash__',
'__init__', '__len__', '__module__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__setitem__',
'__setslice__', '__sizeof__', '__str__', '__subclasshook__',
'__weakref__', '_lock', '_obj', 'acquire', 'get_lock', 'get_obj', 'raw',
'release', 'value']
----------
assignee: georg.brandl
components: Documentation
messages: 76108
nosy: dursobr, georg.brandl
severity: normal
status: open
title: error in multiprocessing docs - rawvalue
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4364>
_______________________________________
From report at bugs.python.org Thu Nov 20 16:55:44 2008
From: report at bugs.python.org (Cournapeau David)
Date: Thu, 20 Nov 2008 15:55:44 +0000
Subject: [New-bugs-announce] [issue4365] Add CRT version info in msvcrt
module
In-Reply-To: <1227196544.3.0.848395658418.issue4365@psf.upfronthosting.co.za>
Message-ID: <1227196544.3.0.848395658418.issue4365@psf.upfronthosting.co.za>
New submission from Cournapeau David <david at ar.media.kyoto-u.ac.jp>:
This patch if the first part to follow discussion on python-list
concerning problems when using distutils.config.try_run with mingw and
manifest problems on windows for python 2.6 (or any python built with
recent VS).
It simply adds strings constant got the msvcrt module, so that they can
be queried in distutils to generate manifest on the fly if needed. I
don't know which approach is best to deal with conditional compilation:
for now, I simply do not add the constants if the constants are not
defined at the C level, but this does not strike as a great idea to me.
----------
components: Windows
files: msvcrt_version_info.diff
keywords: patch
messages: 76112
nosy: cdavid
severity: normal
status: open
title: Add CRT version info in msvcrt module
versions: Python 2.7
Added file: http://bugs.python.org/file12074/msvcrt_version_info.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4365>
_______________________________________
From report at bugs.python.org Thu Nov 20 18:26:59 2008
From: report at bugs.python.org (Akira Kitada)
Date: Thu, 20 Nov 2008 17:26:59 +0000
Subject: [New-bugs-announce] [issue4366] cannot find -lpython2.5 when
buinding Python 2.5.2 on FreeBSD 4.11
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
New submission from Akira Kitada <akitada at gmail.com>:
I get a number of "cannot find -lpython2.5" error when building Python
2.5.2 on FreeBSD 2.5.2 with gcc 2.95.4.
This problem is only occured when I build it with "--enable-shared"
configure option.
This is how you can reproduce this problem.
cd Python-2.5.2
configure --enable-shared
make
and you will get
gcc -shared
build/temp.freebsd-4.11-RELEASE-i386-2.5/usr/home/build/dev/Python-2.5.2/Modules/_struct.o
-L/usr/local/lib -lpython2.5 -o build/lib.freebsd-4.11-RELEASE-i386-2.5/_
struct.so
/usr/libexec/elf/ld: cannot find -lpython2.5
...
/home/build/dev/Python-2.5.2/Modules/_ctypes/libffi/src/x86/sysv.o
-L/usr/local/lib -lpython2.5 -o
build/lib.freebsd-4.11-RELEASE-i386-2.5/_ctypes.so
/usr/libexec/elf/ld: cannot find -lpython2.5
...
gcc -shared
build/temp.freebsd-4.11-RELEASE-i386-2.5/usr/home/build/dev/Python-2.5.2/Modules/_ctypes/_ctypes_test.o
-L/usr/local/lib -lpython2.5 -o build/lib.freebsd-4.11-RELEA
SE-i386-2.5/_ctypes_test.so
/usr/libexec/elf/ld: cannot find -lpython2.5
...
gcc -shared
build/temp.freebsd-4.11-RELEASE-i386-2.5/usr/home/build/dev/Python-2.5.2/Modules/_weakref.o
-L/usr/local/lib -lpython2.5 -o build/lib.freebsd-4.11-RELEASE-i386-2.5/
_weakref.so
/usr/libexec/elf/ld: cannot find -lpython2.5
...
gcc -shared
build/temp.freebsd-4.11-RELEASE-i386-2.5/usr/home/build/dev/Python-2.5.2/Modules/arraymodule.o
-L/usr/local/lib -lpython2.5 -o build/lib.freebsd-4.11-RELEASE-i386-2
.5/array.so
/usr/libexec/elf/ld: cannot find -lpython2.5
......
You can workaround this by running ./configure LDFLAGS="-L."
--enable-shared.
----------
components: Build
messages: 76117
nosy: akitada
severity: normal
status: open
title: cannot find -lpython2.5 when buinding Python 2.5.2 on FreeBSD 4.11
type: compile error
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________
From report at bugs.python.org Thu Nov 20 18:36:07 2008
From: report at bugs.python.org (Giuseppe Ottaviano)
Date: Thu, 20 Nov 2008 17:36:07 +0000
Subject: [New-bugs-announce] [issue4367] Patch for segmentation fault in
ast_for_atom
In-Reply-To: <1227202567.31.0.450419283212.issue4367@psf.upfronthosting.co.za>
Message-ID: <1227202567.31.0.450419283212.issue4367@psf.upfronthosting.co.za>
New submission from Giuseppe Ottaviano <giuott at gmail.com>:
Hi all,
trying to compile Python 2.6 I got a segmentation fault while
byte-compiling the modules.
The segmentation fault happened in ast_for_atom, parsing an Unicode
entity. I found out that another problem prevented unicodedata to be
imported, so unicode_decode raised an exception. I think the problem is
in the following lines:
if (PyErr_ExceptionMatches(PyExc_UnicodeError)){
PyObject *type, *value, *tback, *errstr;
PyErr_Fetch(&type, &value, &tback);
errstr = ((PyUnicodeErrorObject *)value)->reason;
I'm not an expert of CPython internals, but the exception is raised with
PyErr_SetString, so value is a PyStringObject, and that cast is invalid.
Changing the last line to
errstr = value;
everything works.
The patch is attached.
----------
files: ast.patch
keywords: patch
messages: 76119
nosy: ot
severity: normal
status: open
title: Patch for segmentation fault in ast_for_atom
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file12075/ast.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4367>
_______________________________________
From report at bugs.python.org Thu Nov 20 18:43:30 2008
From: report at bugs.python.org (Akira Kitada)
Date: Thu, 20 Nov 2008 17:43:30 +0000
Subject: [New-bugs-announce] [issue4368] a bug in ncurses.h still exist in
Message-ID: <1227203011.0.0.217266498635.issue4368@psf.upfronthosting.co.za>
Changes by Akira Kitada <akitada at gmail.com>:
----------
nosy: akitada
severity: normal
status: open
title: a bug in ncurses.h still exist in
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4368>
_______________________________________
From report at bugs.python.org Thu Nov 20 18:45:00 2008
From: report at bugs.python.org (Giuseppe Ottaviano)
Date: Thu, 20 Nov 2008 17:45:00 +0000
Subject: [New-bugs-announce] [issue4369] Error building to a nonstandard
prefix (with patch)
In-Reply-To: <1227203100.95.0.318644888004.issue4369@psf.upfronthosting.co.za>
Message-ID: <1227203100.95.0.318644888004.issue4369@psf.upfronthosting.co.za>
New submission from Giuseppe Ottaviano <giuott at gmail.com>:
Hi all,
I am trying to compile python 2.6 using a user directory as prefix. In
the the byte-compiling step of install, compileall.py fails to load all
the .so modules (it fails for zlib.so and raises an exception for
unicodedata.so), so the build fails. I think it is because python is
invoked by the makefile with the env variables
PYTHONPATH=$(DESTDIR)$(LIBDEST)
while the .so are in $(LIBDEST)/lib-dynload .
Setting PYTHONHOME instead of PYTHONPATH works for me (but i do not know
if it breaks anything else):
PYTHONHOME=$(exec_prefix)
The patch is attached.
----------
components: Build
files: make.patch
keywords: patch
messages: 76120
nosy: ot
severity: normal
status: open
title: Error building to a nonstandard prefix (with patch)
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file12076/make.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4369>
_______________________________________
From report at bugs.python.org Thu Nov 20 19:20:39 2008
From: report at bugs.python.org (Akira Kitada)
Date: Thu, 20 Nov 2008 18:20:39 +0000
Subject: [New-bugs-announce] [issue4370] warning: unknown conversion type
character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
New submission from Akira Kitada <akitada at gmail.com>:
Some compilers don't understand "%zd" format specifer
and gcc 2.95.4 is one of them.
(You can find more on http://www.and.org/vstr/printf_comparison)
When building Python with such compilers, you will see a lot of
"warning: unknown conversion type character `z' in format" messages.
This is not a big issue but I think this can be fixed by using autoconf
right way because configure script seems checking availability of "zd".
"checking for %zd printf() format support"
So I suppose there is a way to eliminate this warning completely.
----------
components: Build
messages: 76123
nosy: akitada
severity: normal
status: open
title: warning: unknown conversion type character `z' in format
type: compile error
versions: Python 2.5, Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________
From report at bugs.python.org Thu Nov 20 22:39:19 2008
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 20 Nov 2008 21:39:19 +0000
Subject: [New-bugs-announce] [issue4371] coerce gone---but not from docs
In-Reply-To: <1227217159.12.0.256494985843.issue4371@psf.upfronthosting.co.za>
Message-ID: <1227217159.12.0.256494985843.issue4371@psf.upfronthosting.co.za>
New submission from David W. Lambert <lambertdw at corning.com>:
http://docs.python.org/dev/3.0/glossary.html
Scanning the glossary reveals...
coercion
The glossary needs rewritten to eliminate "coerce builtin".
__future__
Uses example import division, I'd replace it but I don't know what
the future holds.
integer division
obvious.
view
not defined in the glossary. Please consider adding this concept.
----------
messages: 76142
nosy: LambertDW
severity: normal
status: open
title: coerce gone---but not from docs
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4371>
_______________________________________
From report at bugs.python.org Thu Nov 20 23:48:47 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 20 Nov 2008 22:48:47 +0000
Subject: [New-bugs-announce] [issue4372] __cmp__ removal not in What's New
In-Reply-To: <1227221327.85.0.608850654298.issue4372@psf.upfronthosting.co.za>
Message-ID: <1227221327.85.0.608850654298.issue4372@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
What's New in Python 3.0/Common stumbling blocks
has this "builtin.sorted() and list.sort() no longer accept the cmp
argument providing a comparison function. Use the key argument instead."
Please add "The __cmp__ special method is no longer used for
comparisons. Use __lt__ for sorting, __eq__ with __hash__, and other
rich comparisons as needed."
People are already stumbling on this.
----------
assignee: georg.brandl
components: Documentation
messages: 76147
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: __cmp__ removal not in What's New
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4372>
_______________________________________
From report at bugs.python.org Fri Nov 21 03:28:59 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 21 Nov 2008 02:28:59 +0000
Subject: [New-bugs-announce] [issue4373] Reference leaks in Python 3.0rc3
In-Reply-To: <1227234539.44.0.916579438082.issue4373@psf.upfronthosting.co.za>
Message-ID: <1227234539.44.0.916579438082.issue4373@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
A refleak test of r67311 py3k shows several leaks:
test_distutils leaked [142, 142, 142, 142] references, sum=568
test_httpservers leaked [0, 0, 0, 217] references, sum=217
test_multiprocessing leaked [0, 0, 24, 0] references, sum=24
test_pickle leaked [1, 1, 1, 1] references, sum=4
test_pickletools leaked [1, 1, 1, 1] references, sum=4
test_telnetlib leaked [-84, 84, 0, 0] references, sum=0
test_threadedtempfile leaked [94, -94, 0, 0] references, sum=0
----------
messages: 76158
nosy: christian.heimes
priority: deferred blocker
severity: normal
stage: test needed
status: open
title: Reference leaks in Python 3.0rc3
type: resource usage
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4373>
_______________________________________
From report at bugs.python.org Fri Nov 21 03:45:51 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 21 Nov 2008 02:45:51 +0000
Subject: [New-bugs-announce] [issue4374] Pickle tests fail w/o _pickle
extension
In-Reply-To: <1227235551.08.0.299604936277.issue4374@psf.upfronthosting.co.za>
Message-ID: <1227235551.08.0.299604936277.issue4374@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
$ rm build/lib.linux-x86_64-3.0-pydebug/_pickle.so
$ ./python Lib/test/regrtest.py -R:: test_pickle
test_pickle
test test_pickle failed -- Traceback (most recent call last):
File "/home/heimes/dev/python/py3k/Lib/test/pickletester.py", line
1032, in test_bad_init
self.assertRaises(pickle.PicklingError, BadPickler().dump, 0)
File "/home/heimes/dev/python/py3k/Lib/unittest.py", line 311, in
failUnlessRaises
callableObj(*args, **kwargs)
File "/home/heimes/dev/python/py3k/Lib/pickle.py", line 225, in dump
if self.proto >= 2:
AttributeError: 'BadPickler' object has no attribute 'proto'
1 test failed:
test_pickle
[59279 refs]
----------
components: Extension Modules, Tests
messages: 76160
nosy: christian.heimes
priority: high
severity: normal
stage: needs patch
status: open
title: Pickle tests fail w/o _pickle extension
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4374>
_______________________________________
From report at bugs.python.org Fri Nov 21 10:53:24 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Fri, 21 Nov 2008 09:53:24 +0000
Subject: [New-bugs-announce] [issue4375] inspect.getsource doesn't work with
PYTHONPATH and source compiled from a different dir
In-Reply-To: <1227261204.44.0.0137459794576.issue4375@psf.upfronthosting.co.za>
Message-ID: <1227261204.44.0.0137459794576.issue4375@psf.upfronthosting.co.za>
New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:
I'm running into a similar problem as Jean-Paul in:
http://bugs.python.org/issue4223
But the patch in it doesn't work for me. My issue is also with files
compiled already with python3.0, but then being accessed from a
different location using PYTHONPATH. Here's a full example of the
problem:
mkdir dir1
mkdir dir1/foo
mkdir dir2
echo 'def f(): pass' > dir1/foo/__init__.py
cd dir1
python3.0 -c "import foo"
cd ../dir2
python3.0 -c "import inspect, sys; sys.path.append('../dir1'); import
foo; print(inspect.getsource(foo.f))"
Which errors out with:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/inspect.py", line 691, in getsource
lines, lnum = getsourcelines(object)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/inspect.py", line 680, in getsourcelines
lines, lnum = findsource(object)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/inspect.py", line 528, in findsource
raise IOError('could not get source code')
IOError: could not get source code
If I instrument inspect, it looks like what's happening is that
linecache is being passed f.__code__.co_filename. However with the
sys.path manipulation, that filename is baked into the .pyc file as
"foo/__init__.py". This confuses linecache which can't find the file.
Here's one suggestion of a fix.
--- /tmp/inspect.py 2008-11-21 01:34:56.000000000 -0800
+++ /opt/local/lib/python3.0/inspect.py 2008-11-21 01:35:28.000000000 -
0800
@@ -518,6 +518,7 @@
is raised if the source code cannot be retrieved."""
file = getsourcefile(object) or getfile(object)
module = getmodule(object, file)
+ file = getsourcefile(module) or getfile(file)
if module:
lines = linecache.getlines(file, module.__dict__)
else:
It looks like in most situations the module has an accurate __file__
that's updated from PYTHONPATH. I'm not sure if this works in every
situation, but this, along with the other patch, work together to get
the source printing working.
----------
components: Library (Lib)
messages: 76170
nosy: erickt
severity: normal
status: open
title: inspect.getsource doesn't work with PYTHONPATH and source compiled from a different dir
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4375>
_______________________________________
From report at bugs.python.org Fri Nov 21 11:09:31 2008
From: report at bugs.python.org (Aaron Brady)
Date: Fri, 21 Nov 2008 10:09:31 +0000
Subject: [New-bugs-announce] [issue4376] Nested ctypes 'BigEndianStructure'
fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
New submission from Aaron Brady <castironpi at gmail.com>:
Nested 'BigEndianStructure' fails in 2.5 and 2.6.:
TypeError: This type does not support other endian
Example and traceback in attached file.
----------
assignee: theller
components: ctypes
files: ng36.py
messages: 76171
nosy: castironpi, theller
severity: normal
status: open
title: Nested ctypes 'BigEndianStructure' fails
type: compile error
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file12091/ng36.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________
From report at bugs.python.org Fri Nov 21 13:32:19 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Nov 2008 12:32:19 +0000
Subject: [New-bugs-announce] [issue4377] tokenize.detect_encoding() and Mac
newline
In-Reply-To: <1227270739.29.0.218620905737.issue4377@psf.upfronthosting.co.za>
Message-ID: <1227270739.29.0.218620905737.issue4377@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
I'm trying to fix IDLE to support Unicode (#4008 and #4323). Instead
of IDLE builtin charset detection, I tried to use
tokenize.detect_encoding() but this function doesn't work with script
using Mac new line (b"\r").
Code to detect the encoding of a Python script:
----
def pythonEncoding(filename):
with open(filename, 'rb') as fp:
encoding, lines = detect_encoding(fp.readline)
return encoding
----
Example to reproduce the problem with Mac script:
----
fp = BytesIO(b'# coding: ISO-8859-1\rprint("Bonjour ma ch\xe8re
amie")\r')
encoding, lines = detect_encoding(fp.readline)
print(encoding, lines)
----
=> Result: utf-8 [b'# coding: ISO-8859-1\rprint("Bonjour ma ch\xe8re
amie")\r']
The problem occurs at "line_string = line.decode('ascii')".
Since "line" contains a non-ASCII character (b"\xe8"), the conversion
fails.
----------
components: Library (Lib)
messages: 76176
nosy: haypo
severity: normal
status: open
title: tokenize.detect_encoding() and Mac newline
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4377>
_______________________________________
From report at bugs.python.org Fri Nov 21 17:45:58 2008
From: report at bugs.python.org (David W. Lambert)
Date: Fri, 21 Nov 2008 16:45:58 +0000
Subject: [New-bugs-announce] [issue4378] howto doc update
In-Reply-To: <1227285958.71.0.314109568339.issue4378@psf.upfronthosting.co.za>
Message-ID: <1227285958.71.0.314109568339.issue4378@psf.upfronthosting.co.za>
New submission from David W. Lambert <lambertdw at corning.com>:
http://docs.python.org/dev/3.0/howto/functional.html
Gone:
itertools.ifilter
itertools.imap
itertools.izip
changed:
itertools.ifilterfalse --> itertools.filterfalse
strange?
functools.reduce is described, but not with functools.
The section requests comments be mailed directly to author. Done.
----------
assignee: georg.brandl
components: Documentation
messages: 76190
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: howto doc update
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4378>
_______________________________________
From report at bugs.python.org Fri Nov 21 18:20:06 2008
From: report at bugs.python.org (Kevin Watters)
Date: Fri, 21 Nov 2008 17:20:06 +0000
Subject: [New-bugs-announce] [issue4379] Py_SAFE_DOWNCAST in
FILE_TIME_to_time_t_nsec failing
In-Reply-To: <1227288006.53.0.353699707167.issue4379@psf.upfronthosting.co.za>
Message-ID: <1227288006.53.0.353699707167.issue4379@psf.upfronthosting.co.za>
New submission from Kevin Watters <kevinwatters at gmail.com>:
After releasing a Py_DEBUG build to some users who were experiencing
problems, I noticed a pattern in some of the crash reports I got back:
msvcr90d!_wassert+0xb64
python25_d!FILE_TIME_to_time_t_nsec+0xac
python25_d!attribute_data_to_stat+0x67
python25_d!win32_wstat+0x6f
python25_d!posix_do_stat+0x51
python25_d!posix_stat+0x24
python25_d!PyCFunction_Call+0x65
python25_d!call_function+0x34f
python25_d!PyEval_EvalFrameEx+0x4741
The only way I can see _wassert being hit in FILE_TIME_to_time_t_nsec is
in the Py_SAFE_DOWNCAST used to downcast an __int64 to int.
Py_SAFE_DOWNCAST checks that there is equality between the casted and
non-casted values with Py_DEBUG enabled--maybe in this function we
should remove Py_SAFE_DOWNCAST?
I can't find a way to see the actual value for "in" before the assert is
hit--I'm unfamiliar with picking through minidumps with WinDbg, which
for some reason will show me the stack for these dumps when Visual
Studio won't. But if I need to investigate more about them I can.
----------
components: None
messages: 76193
nosy: kevinwatters
severity: normal
status: open
title: Py_SAFE_DOWNCAST in FILE_TIME_to_time_t_nsec failing
type: behavior
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4379>
_______________________________________
From report at bugs.python.org Fri Nov 21 21:20:48 2008
From: report at bugs.python.org (Kevin Fitch)
Date: Fri, 21 Nov 2008 20:20:48 +0000
Subject: [New-bugs-announce] [issue4380] Deepcopy of functools.partial gives
wierd exception
In-Reply-To: <1227298848.26.0.43954537451.issue4380@psf.upfronthosting.co.za>
Message-ID: <1227298848.26.0.43954537451.issue4380@psf.upfronthosting.co.za>
New submission from Kevin Fitch <kfitch42 at gmail.com>:
from functools import partial
from copy import deepcopy
p = partial("Hello world".replace, "world")
p("mom")
p2 = deepcopy(p)
The output I get is:
Hello mom
Followed by:
<type 'exceptions.TypeError'> Traceback (most recent call last)
/home/kfitch/<ipython console> in <module>()
/usr/lib/python2.5/copy.py in deepcopy(x, memo, _nil)
187 raise Error(
188 "un(deep)copyable object of type
%s" % cls)
--> 189 y = _reconstruct(x, rv, 1, memo)
190
191 memo[d] = y
/usr/lib/python2.5/copy.py in _reconstruct(x, info, deep, memo)
320 if deep:
321 args = deepcopy(args, memo)
--> 322 y = callable(*args)
323 memo[id(x)] = y
324 if listiter is not None:
/usr/lib/python2.5/copy_reg.py in __newobj__(cls, *args)
90
91 def __newobj__(cls, *args):
---> 92 return cls.__new__(cls, *args)
93
94 def _slotnames(cls):
<type 'exceptions.TypeError'>: type 'partial' takes at least one argument
I am not entirely convinced that doing a deepcopy on a partial makes
sense, but I would expect one of:
1) An explicit exception saying it isn't allowed
2) Returning the original partial object
3) An actual copy (should the arguments its storing get deepcopied?)
P.S. This is with 2.5.2 under Linux (Ubuntu 8.04)
----------
messages: 76200
nosy: kfitch
severity: normal
status: open
title: Deepcopy of functools.partial gives wierd exception
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4380>
_______________________________________
From report at bugs.python.org Fri Nov 21 21:33:45 2008
From: report at bugs.python.org (Kevin Fitch)
Date: Fri, 21 Nov 2008 20:33:45 +0000
Subject: [New-bugs-announce] [issue4381] Cannot declare multiple classes via
exec when inside a function.
In-Reply-To: <1227299625.55.0.683059455596.issue4381@psf.upfronthosting.co.za>
Message-ID: <1227299625.55.0.683059455596.issue4381@psf.upfronthosting.co.za>
New submission from Kevin Fitch <kfitch42 at gmail.com>:
codeText = """
class foo(object): pass
class bar(object):
baz = foo()
"""
def doExec(text):
exec text
### This works:
# Although if I do this before the doExec below, then the
# doExec doesn't fail.
# exec codeText
### But this does not:
doExec(codeText)
The output I get is:
---------------------------------------------------------------------------
<type 'exceptions.NameError'> Traceback (most recent call last)
/home/kfitch/<ipython console> in <module>()
/home/kfitch/<ipython console> in doExec(text)
/home/kfitch/<string> in <module>()
/home/kfitch/<string> in bar()
<type 'exceptions.NameError'>: name 'foo' is not defined
I don't fully understand why the version in the function doesn't work,
but I suspect it is a bug related to scoping, since foo is really
doExec.foo (I think).
This is with python 2.5.2 under Linux (Ubuntu 8.04)
----------
messages: 76202
nosy: kfitch
severity: normal
status: open
title: Cannot declare multiple classes via exec when inside a function.
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4381>
_______________________________________
From report at bugs.python.org Fri Nov 21 23:15:18 2008
From: report at bugs.python.org (Martina Oefelein)
Date: Fri, 21 Nov 2008 22:15:18 +0000
Subject: [New-bugs-announce] [issue4382] test_dbm_dumb fails due to
character encoding issue on Mac OS X
In-Reply-To: <1227305718.24.0.821322507484.issue4382@psf.upfronthosting.co.za>
Message-ID: <1227305718.24.0.821322507484.issue4382@psf.upfronthosting.co.za>
New submission from Martina Oefelein <Martina at oefelein.de>:
test_dbm_dumb fails due to what appears to be a character encoding issue
on Mac OS X:
Majestix:Python-3.0rc3 martina$
DYLD_FRAMEWORK_PATH=/Users/martina/Downloads/Python-3.0rc3: ./python.exe
-E -bb ./Lib/test/regrtest.py -l test_dbm_dumbtest_dbm_dumb
Exception UnicodeEncodeError: UnicodeEncodeError('charmap', "'??',
(3072, 1)\n", 2, 3, 'character maps to <undefined>') in <bound method
_Database.close of <dbm.dumb._Database object at 0x6a2510>> ignored
Exception UnicodeEncodeError: UnicodeEncodeError('charmap', "'??',
(3072, 1)\n", 2, 3, 'character maps to <undefined>') in <bound method
_Database.close of <dbm.dumb._Database object at 0x6a2510>> ignored
Exception UnicodeEncodeError: UnicodeEncodeError('charmap', "'??',
(3072, 1)\n", 2, 3, 'character maps to <undefined>') in <bound method
_Database.close of <dbm.dumb._Database object at 0x6a2510>> ignored
Exception UnicodeEncodeError: UnicodeEncodeError('charmap', "'??',
(3072, 1)\n", 2, 3, 'character maps to <undefined>') in <bound method
_Database.close of <dbm.dumb._Database object at 0x6a2510>> ignored
Exception UnicodeEncodeError: UnicodeEncodeError('charmap', "'??',
(3072, 1)\n", 2, 3, 'character maps to <undefined>') in <bound method
_Database.close of <dbm.dumb._Database object at 0x6a2550>> ignored
Exception UnicodeEncodeError: UnicodeEncodeError('charmap', "'??',
(3072, 1)\n", 2, 3, 'character maps to <undefined>') in <bound method
_Database.close of <dbm.dumb._Database object at 0x6a2550>> ignored
test test_dbm_dumb failed -- errors occurred; run in verbose mode for
details
1 test failed:
test_dbm_dumb
----------
components: Library (Lib), Macintosh, Tests
messages: 76208
nosy: oefe
severity: normal
status: open
title: test_dbm_dumb fails due to character encoding issue on Mac OS X
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4382>
_______________________________________
From report at bugs.python.org Fri Nov 21 23:42:48 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Nov 2008 22:42:48 +0000
Subject: [New-bugs-announce] [issue4383] UnboundLocalError when IDLE cannot
connect to its subprocess
In-Reply-To: <1227307368.24.0.863282757951.issue4383@psf.upfronthosting.co.za>
Message-ID: <1227307368.24.0.863282757951.issue4383@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
When IDLE cannot connect to its subprocess, it tries to display the
socket.error. But since python 3.0 the exception variable is cleared
after the "except:" block and unavailable for the displaying code.
Exception in thread SockThread:
Traceback (most recent call last):
File "c:\dev\python\py3k\lib\threading.py", line 507, in
_bootstrap_inner
self.run()
File "c:\dev\python\py3k\lib\threading.py", line 462, in run
self._target(*self._args, **self._kwargs)
File "c:\dev\python\py3k\lib\idlelib\run.py", line 125, in
manage_socket
show_socket_error(err, address)
UnboundLocalError: local variable 'err' referenced before assignment
Patch is attached.
----------
components: IDLE
files: idle_socketerror.patch
keywords: needs review, patch
messages: 76213
nosy: amaury.forgeotdarc
priority: release blocker
severity: normal
status: open
title: UnboundLocalError when IDLE cannot connect to its subprocess
versions: Python 3.0
Added file: http://bugs.python.org/file12103/idle_socketerror.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4383>
_______________________________________
From report at bugs.python.org Sat Nov 22 00:21:38 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2008 23:21:38 +0000
Subject: [New-bugs-announce] [issue4384] Add a warnings.showwarning
replacement for logging
In-Reply-To: <1227309698.77.0.511874051241.issue4384@psf.upfronthosting.co.za>
Message-ID: <1227309698.77.0.511874051241.issue4384@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
It would be nice if the logging package provided a replacement for
warnings.showwarning() so that all warning redirect to the logging package.
----------
components: Library (Lib)
keywords: easy
messages: 76221
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a warnings.showwarning replacement for logging
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4384>
_______________________________________
From report at bugs.python.org Sat Nov 22 00:43:57 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 21 Nov 2008 23:43:57 +0000
Subject: [New-bugs-announce] [issue4385] Py_Object_HEAD_INIT in Py3k
In-Reply-To: <1227311037.4.0.355018022535.issue4385@psf.upfronthosting.co.za>
Message-ID: <1227311037.4.0.355018022535.issue4385@psf.upfronthosting.co.za>
New submission from Nick Coghlan <ncoghlan at gmail.com>:
The memory layout of PyType object's changes in Py3k from the
*compiler's* point of view. This means PyObject_HEAD_INIT can no longer
be used to initialise PyVarObject type definitions.
However, the documentation doesn't point this out (or document
PyVarObject_HEAD_INIT at all), and the compiler warnings currently
generated are not clear. Suggestion is to remove PyObject_HEAD_INIT from
Py3k entirely so this becomes a compile error instead of a warning, and
then better document the situation so extension authors know how to
correctly initialise the affected C structs.
See mailing list thread at:
http://mail.python.org/pipermail/python-3000/2008-November/015241.html
----------
components: Interpreter Core
messages: 76224
nosy: ncoghlan
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Py_Object_HEAD_INIT in Py3k
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4385>
_______________________________________
From report at bugs.python.org Sat Nov 22 01:13:19 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 22 Nov 2008 00:13:19 +0000
Subject: [New-bugs-announce] [issue4386] A binary file should show "b" in
its mode
In-Reply-To: <1227312799.3.0.532336276837.issue4386@psf.upfronthosting.co.za>
Message-ID: <1227312799.3.0.532336276837.issue4386@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
The changes following r67300 introduced the .mode and .name attributes on all
the file-like objects returned by the open() function.
This also changed the mode returned by a file opened in binary mode: it was
"rb", now it is "r". The fact that the mode does not "round-trip" (i.e: open(f,
mode).mode != mode) was considered not important.
But now it is difficult to see if some opened file was opened in text or binary
mode; in test_gzip.py, a test had to be changed, and now it does not test
anything at all: the intent of the test is just to verify that a zip file is
always opened in binary mode.
Benjamin suggested to change the mode returned by FileIO objects, so that they
always contain a 'b'. They also accept an extra 'b' on creation: it is just
ignored.
Now, for a file opened in text mode:
>>> f = open('filename')
>>> assert f.mode == 'r'
>>> assert f.buffer.mode == 'rb'
>>> assert f.buffer.raw.mode == 'rb'
The mode attribute is now always consistent with the one passed to the open()
function. This also avoid gratuitous breakage with python2.x.
Patch attached. All tests pass.
----------
assignee: benjamin.peterson
files: fileio_mode.patch
keywords: needs review, patch
messages: 76225
nosy: amaury.forgeotdarc, benjamin.peterson
priority: release blocker
severity: normal
stage: patch review
status: open
title: A binary file should show "b" in its mode
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12104/fileio_mode.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4386>
_______________________________________
From report at bugs.python.org Sat Nov 22 01:41:19 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Nov 2008 00:41:19 +0000
Subject: [New-bugs-announce] [issue4387] binascii b2a functions accept
strings (unicode) as data
In-Reply-To: <1227314479.85.0.870718938291.issue4387@psf.upfronthosting.co.za>
Message-ID: <1227314479.85.0.870718938291.issue4387@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
Binascii b2a_xxx functions accept 'binary data' and return ascii-encoded
bytes. The corresponding a2b_xxx functions turn the ascii-encoded bytes
back to 'binary data' (bytes). If the binary data is bytes, these
should be inverses of each other.
Somewhat surprisingly to me (because the corresponding base64 module
functions raise "TypeError: expected bytes, not str") 3.0 strings
(unicode) are accepted as 'binary data', though they will not 'round-trip'.
Ascii chars almost do
>>> a='aaaa'
>>> c=b.b2a_base64(a)
>>> c
b'YWFhYQ==\n'
>>> d=b.a2b_base64(c)
>>> d
b'aaaa'
But general unicode chars generate nonsense.
>>> a='\u1000'
>>> c=b.b2a_base64(a)
>>> c
b'4YCA\n'
>>> d=b.a2b_base64(c)
>>> d
b'\xe1\x80\x80'
I also tried b2a_uu.
Is this a bug?
----------
components: Extension Modules
messages: 76226
nosy: tjreedy
severity: normal
status: open
title: binascii b2a functions accept strings (unicode) as data
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4387>
_______________________________________
From report at bugs.python.org Sat Nov 22 05:54:41 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sat, 22 Nov 2008 04:54:41 +0000
Subject: [New-bugs-announce] [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
New submission from Jean Brouwers <MrJean1 at Gmail.com>:
There is one test failure with Python 3.0rc3 built on MacOS X 10.4.11
(Intel). Test test_cmd_line fails in the very last test as follows:
% python.exe Lib/test/test_cmd_line.py
test_directories (__main__.CmdLineTest) ... ok
test_optimize (__main__.CmdLineTest) ... ok
test_q (__main__.CmdLineTest) ... ok
test_run_code (__main__.CmdLineTest) ... FAIL
test_run_module (__main__.CmdLineTest) ... ok
test_run_module_bug1764407 (__main__.CmdLineTest) ... ok
test_site_flag (__main__.CmdLineTest) ... ok
test_usage (__main__.CmdLineTest) ... ok
test_verbose (__main__.CmdLineTest) ... ok
test_version (__main__.CmdLineTest) ... ok
======================================================================
FAIL: test_run_code (__main__.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib/test/test_cmd_line.py", line 143, in test_run_code
0)
AssertionError: 1 != 0
----------------------------------------------------------------------
Ran 10 tests in 2.074s
FAILED (failures=1)
Traceback (most recent call last):
File "Lib/test/test_cmd_line.py", line 151, in <module>
test_main()
File "Lib/test/test_cmd_line.py", line 147, in test_main
test.support.run_unittest(CmdLineTest)
File ".../Python-3.0rc3/Lib/test/support.py", line 698, in
run_unittest
_run_suite(suite)
File ".../Python-3.0rc3/Lib/test/support.py", line 681, in _run_suite
raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
File "Lib/test/test_cmd_line.py", line 143, in test_run_code
0)
AssertionError: 1 != 0
The results for this code snippet:
# Test handling of non-ascii data
if sys.getfilesystemencoding() != 'ascii':
command = "assert(ord('\xe9') == 0xe9)"
self.assertEqual(
self.exit_code('-c', command),
0)
are:
% python.exe
Python 3.0rc3 (r30rc3:67312, Nov 21 2008, 14:20:38)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getfilesystemencoding()
'utf-8'
>>> ord('\xe9') == 0xe9
True
----------
components: Tests
messages: 76232
nosy: MrJean1
severity: normal
status: open
title: test_cmd_line fails on MacOS X
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________
From report at bugs.python.org Sat Nov 22 15:17:52 2008
From: report at bugs.python.org (Retro)
Date: Sat, 22 Nov 2008 14:17:52 +0000
Subject: [New-bugs-announce] [issue4389] Uninstaller Lacks an Icon
In-Reply-To: <1227363472.79.0.655379439332.issue4389@psf.upfronthosting.co.za>
Message-ID: <1227363472.79.0.655379439332.issue4389@psf.upfronthosting.co.za>
New submission from Retro <vinetouu at gmail.com>:
The uninstaller program of the Python interpreter lacks an icon. This
looks ackward in the Add/Remove Programs list on the Windows platform.
Please add an icon for the uninstaller.
----------
components: None
messages: 76246
nosy: Retro
severity: normal
status: open
title: Uninstaller Lacks an Icon
versions: Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4389>
_______________________________________
From report at bugs.python.org Sat Nov 22 21:28:04 2008
From: report at bugs.python.org (Krzysztof Pawlik)
Date: Sat, 22 Nov 2008 20:28:04 +0000
Subject: [New-bugs-announce] [issue4390] Using subprocess.STDOUT causes
AttributeError
In-Reply-To: <1227385684.57.0.612346460574.issue4390@psf.upfronthosting.co.za>
Message-ID: <1227385684.57.0.612346460574.issue4390@psf.upfronthosting.co.za>
New submission from Krzysztof Pawlik <krzysiek.pawlik at people.pl>:
Using stderr=subprocess.STDOUT causes Python 3.0 (RC1 from Ubuntu 8.10)
to raise AttributeError, important code snippet (whole test program
attached):
proc = subprocess.Popen(['whoami'], stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
stdout, stderr = proc.communicate()
nelchael at nelchael-vbox ~$ python2.5 --version
Python 2.5.2
nelchael at nelchael-vbox ~$ python2.5 test-subprocess.py
('stdout:', 'nelchael\n')
('stderr:', None)
nelchael at nelchael-vbox ~$ python3 --version
Python 3.0rc1+
nelchael at nelchael-vbox ~$ python3 test-subprocess.py
Traceback (most recent call last):
File "test-subprocess.py", line 4, in <module>
stdout, stderr = proc.communicate()
File "/usr/lib/python3.0/subprocess.py", line 663, in communicate
stdout = self._fo_read_no_intr(self.stdout)
AttributeError: 'Popen' object has no attribute '_fo_read_no_intr'
nelchael at nelchael-vbox ~$
----------
components: Library (Lib)
files: test-subprocess.py
messages: 76258
nosy: nelchael
severity: normal
status: open
title: Using subprocess.STDOUT causes AttributeError
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12106/test-subprocess.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4390>
_______________________________________
From report at bugs.python.org Sat Nov 22 22:44:28 2008
From: report at bugs.python.org (Dwayne Bailey)
Date: Sat, 22 Nov 2008 21:44:28 +0000
Subject: [New-bugs-announce] [issue4391] optparse: use proper gettext
plurals forms
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
New submission from Dwayne Bailey <dwayne+pythonbugs at translate.org.za>:
The following code in optparse:
if len(rargs) < nargs:
if nargs == 1:
self.error(_("%s option requires an argument") % opt)
else:
self.error(_("%s option requires %d arguments")
% (opt, nargs))
works for languages with plurals of n!=1 but will not work for many
others that have more sophisticated plurals.
I've created a patch that handles missing gettext and implements it
correctly if it is available. Be aware that I have not been able to test
the patch.
----------
components: Library (Lib)
files: optparse_proper_gettext_plurals.diff
keywords: patch
messages: 76260
nosy: dwayne
severity: normal
status: open
title: optparse: use proper gettext plurals forms
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file12107/optparse_proper_gettext_plurals.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4391>
_______________________________________
From report at bugs.python.org Sun Nov 23 08:17:11 2008
From: report at bugs.python.org (none_00)
Date: Sun, 23 Nov 2008 07:17:11 +0000
Subject: [New-bugs-announce] [issue4392] incorrect parameter name for
collections.namedtuple
In-Reply-To: <1227424631.44.0.100708165737.issue4392@psf.upfronthosting.co.za>
Message-ID: <1227424631.44.0.100708165737.issue4392@psf.upfronthosting.co.za>
New submission from none_00 <nanikata at gmail.com>:
http://docs.python.org/library/collections.html#collections.namedtuple
it is stated that the second parameter to namedtuple
is "fieldnames", while in reality it is "field_names"
----------
assignee: georg.brandl
components: Documentation
messages: 76265
nosy: georg.brandl, none_00
severity: normal
status: open
title: incorrect parameter name for collections.namedtuple
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4392>
_______________________________________
From report at bugs.python.org Sun Nov 23 13:28:26 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 Nov 2008 12:28:26 +0000
Subject: [New-bugs-announce] [issue4393] Portability fixes in longobject.c
In-Reply-To: <1227443306.12.0.492255652415.issue4393@psf.upfronthosting.co.za>
Message-ID: <1227443306.12.0.492255652415.issue4393@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
This patch fixes 3 classes of bugs in Objects/longobject.c:
(1) declarations of a variable (usually a counter into the digits of
a PyLong) as int instead of Py_ssize_t.
(2) missing (twodigits) casts from multiplies and shifts.
(3) use of '<<' on negative values in _PyLong_AsByteArray. This
may lead to undefined behaviour, according to the C standards. (See C99,
section 6.5.7, paragraph 4).
These bugs haven't manifested themselves in practice. For (1), there's
only a problem when dealing with huge integers (more than 2**31 digits).
The bugs in (2) can only affect platform where the C 'int' type has fewer
than 32 bits. (3) could potentially conflict with future compiler
optimizations, but doesn't seem to be a problem right now.
For these reasons I don't think these fixes should be backported to 2.5.3.
----------
components: Interpreter Core
files: longobject_casts.patch
keywords: patch
messages: 76267
nosy: marketdickinson
priority: normal
severity: normal
stage: patch review
status: open
title: Portability fixes in longobject.c
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12109/longobject_casts.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4393>
_______________________________________
From report at bugs.python.org Sun Nov 23 15:58:32 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 23 Nov 2008 14:58:32 +0000
Subject: [New-bugs-announce] [issue4394] make the storage of the password
optional in .pypirc (using the prompt)
In-Reply-To: <1227452312.43.0.331068752879.issue4394@psf.upfronthosting.co.za>
Message-ID: <1227452312.43.0.331068752879.issue4394@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
Right now you HAVE to store a clear text password in .pypirc.
But this should not be necessary since the "register" command does a
getpass.getpass call to get the password from the prompt and use it to
authenticate to pypi.
So what do we miss ?
We miss a bit of persistency for the upload command to get that password
when register + upload have been called in the same command line, typically:
$ python setup.py register sdist upload
this patch does it, and adds a test for it.
I am wondering though if upload wouldn't be better not to depend on a
previous call to register (basically by adding a getpass.getpass call
there too), but this can be a second patch.
----------
components: Distutils
files: no_password.patch
keywords: patch
messages: 76268
nosy: tarek
severity: normal
status: open
title: make the storage of the password optional in .pypirc (using the prompt)
type: feature request
versions: Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12110/no_password.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4394>
_______________________________________
From report at bugs.python.org Sun Nov 23 19:21:33 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Nov 2008 18:21:33 +0000
Subject: [New-bugs-announce] [issue4395] Document auto __ne__ generation
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
3.0c3 doc (Basic customization) says
"There are no implied relationships among the comparison operators. The
truth of x==y does not imply that x!=y is false. Accordingly, when
defining __eq__(), one should also define __ne__() so that the operators
will behave as expected. "
In http://mail.python.org/pipermail/python-ideas/2008-October/002235.html
Guido says
"I should also note that part of George's proposal has already been
implemented: if you define __eq__, you get a complementary __ne__ for
free. However it doesn't work the other way around (defining __ne__
doesn't give you __eq__ for free), and there is no similar
relationship for the ordering operators."
And indeed, as Arnaud Delobelle posted on python-list
class A:
def __init__(self, x):
self.x = x
def __eq__(self, other):
return self.x == other.x
a, b, c = A(1), A(1), A(2)
print(a==b, b==c, c==a) # True, False, False
print(a!=b, b!=c, c!=a) # False, True, True
Suggested revision:
"There is one implied relationship among comparison operators: defining
__eq__ gives an automatic __ne__ (but not the other way). There is no
similar relationship for the order comparisons.
----------
assignee: georg.brandl
components: Documentation
messages: 76270
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Document auto __ne__ generation
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4395>
_______________________________________
From report at bugs.python.org Sun Nov 23 20:07:08 2008
From: report at bugs.python.org (David Binger)
Date: Sun, 23 Nov 2008 19:07:08 +0000
Subject: [New-bugs-announce] [issue4396] parser module fails to validate
"with" statements.
In-Reply-To: <1227467228.52.0.497056133571.issue4396@psf.upfronthosting.co.za>
Message-ID: <1227467228.52.0.497056133571.issue4396@psf.upfronthosting.co.za>
New submission from David Binger <davidbinger at mac.com>:
The parser module validates node trees when they are built from sequences.
The validator must, unfortunately, be updated every time there is a change
in the grammar. The current validator fails to validate "with"
statements. This bug probably exists in earlier versions of python
that support "with", but I haven't checked.
Here is a patch with a unit test for py3k.
Files involved: parsermodule.c, test_parser.py.
----------
components: Library (Lib)
files: parsewith.diff
keywords: patch
messages: 76271
nosy: dbinger
severity: normal
status: open
title: parser module fails to validate "with" statements.
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12111/parsewith.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4396>
_______________________________________
From report at bugs.python.org Sun Nov 23 22:29:10 2008
From: report at bugs.python.org (Martina Oefelein)
Date: Sun, 23 Nov 2008 21:29:10 +0000
Subject: [New-bugs-announce] [issue4397] test_socket fails occassionaly in
teardown: AssertionError: [Errno 57] Socket is not connected
In-Reply-To: <1227475750.08.0.401391689781.issue4397@psf.upfronthosting.co.za>
Message-ID: <1227475750.08.0.401391689781.issue4397@psf.upfronthosting.co.za>
New submission from Martina Oefelein <Martina at oefelein.de>:
test_socket fails randomly in about 1 of 50 iterations (MacOS X 10.5.5
intel):
$ for ((;;)); do DYLD_FRAMEWORK_PATH=/Users/martina/Downloads/Python-
3.0rc3: ./python.exe -E -bb ./Lib/test/regrtest.py -l test_socket;done
test_socket
1 test OK.
...
test_socket
test test_socket failed -- Traceback (most recent call last):
File "/Users/martina/Downloads/Python-3.0rc3/Lib/test/test_socket.py",
line 121, in _tearDown
self.fail(msg)
AssertionError: [Errno 57] Socket is not connected
1 test failed:
test_socket
test_socket
1 test OK.
...
----------
components: Library (Lib), Macintosh, Tests
messages: 76276
nosy: oefe
severity: normal
status: open
title: test_socket fails occassionaly in teardown: AssertionError: [Errno 57] Socket is not connected
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4397>
_______________________________________
From report at bugs.python.org Sun Nov 23 22:44:06 2008
From: report at bugs.python.org (Derek Hval)
Date: Sun, 23 Nov 2008 21:44:06 +0000
Subject: [New-bugs-announce] [issue4398] erewer
Message-ID: <1227476646.49.0.778751244258.issue4398@psf.upfronthosting.co.za>
Changes by Derek Hval <der74hva3 at yahoo.com>:
----------
files: aa.html
nosy: der74hva3
severity: normal
status: open
title: erewer
type: compile error
Added file: http://bugs.python.org/file12112/aa.html
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4398>
_______________________________________
From report at bugs.python.org Sun Nov 23 22:55:29 2008
From: report at bugs.python.org (David W. Lambert)
Date: Sun, 23 Nov 2008 21:55:29 +0000
Subject: [New-bugs-announce] [issue4399] "shard" appears where "shared"
intended
In-Reply-To: <1227477329.38.0.775674135763.issue4399@psf.upfronthosting.co.za>
Message-ID: <1227477329.38.0.775674135763.issue4399@psf.upfronthosting.co.za>
New submission from David W. Lambert <lambertdw at corning.com>:
http://docs.python.org/dev/3.0/library/ctypes.html
insert "e" into "shard".
Errors have dissimilar importance. The manual is so good that this is
the worst I can find today.
----------
assignee: georg.brandl
components: Documentation
messages: 76277
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: "shard" appears where "shared" intended
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4399>
_______________________________________
From report at bugs.python.org Mon Nov 24 01:54:46 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 24 Nov 2008 00:54:46 +0000
Subject: [New-bugs-announce] [issue4400] pypirc default is not at the right
format
In-Reply-To: <1227488086.59.0.445845858702.issue4400@psf.upfronthosting.co.za>
Message-ID: <1227488086.59.0.445845858702.issue4400@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
when generated the default pypirc format is wrong, this patch fixes it
(could be backported in 2.6)
----------
components: Distutils
files: fix_pypirc_default.diff
keywords: patch
messages: 76286
nosy: tarek
severity: normal
status: open
title: pypirc default is not at the right format
versions: Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12115/fix_pypirc_default.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4400>
_______________________________________
From report at bugs.python.org Mon Nov 24 02:24:51 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Nov 2008 01:24:51 +0000
Subject: [New-bugs-announce] [issue4401] os.extsep status? doc or os bug?
In-Reply-To: <1227489891.63.0.655964178885.issue4401@psf.upfronthosting.co.za>
Message-ID: <1227489891.63.0.655964178885.issue4401@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
3.0c3 Manual (as with 2.x):
os.extsep
The character which separates the base filename from the extension; for
example, the '.' in os.py. Also available via os.path.
3.0c3
>>> import os
>>> os.extsep
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'extsep'
>>> os.path.extsep
'.'
os.extsep apparently was present in 2.x
Mention of os.extsep was also present in 2.x docstring and removed in
3.0 docstring, so perhaps this was intentional, but it does not make
much sense, so I am provisionally marking this as a library bug.
----------
components: Library (Lib)
messages: 76290
nosy: tjreedy
severity: normal
status: open
title: os.extsep status? doc or os bug?
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4401>
_______________________________________
From report at bugs.python.org Mon Nov 24 03:21:01 2008
From: report at bugs.python.org (=?utf-8?q?=E8=B5=B5=E7=8E=B0=E5=88=9A?=)
Date: Mon, 24 Nov 2008 02:21:01 +0000
Subject: [New-bugs-announce] [issue4402] os.getenv('PATH') return different
result between 2.5 and 3.0rc3
In-Reply-To: <1227493261.31.0.743303269102.issue4402@psf.upfronthosting.co.za>
Message-ID: <1227493261.31.0.743303269102.issue4402@psf.upfronthosting.co.za>
New submission from ??? <zhaolu8 at hotmail.com>:
I am using windows xp(sp3),chinese simplified.I found that in os
module,os.getenv('PATH') return different result between python 2.5 and
3.0rc3.py2.5's result is the same as the path command's result.
path command's result:
PATH=C:\Tcl\bin;C:\oracle\product\10.2.0\db_1
\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\Program
Files\Borland\Delphi7\Bin;C:\Program Files\Borland\Delphi7
\Projects\Bpl\;C:\Program Files\Java\jdk1.7.0\bin;C:\Python25
\;C:\Python30\;...
py2.5's result:
C:\Tcl\bin;C:\oracle\product\10.2.0\db_1
\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\Program
Files\Borland\Delphi7\Bin;C:\Program Files\Borland\Delphi7
\Projects\Bpl\;C:\Program Files\Java\jdk1.7.0\bin;C:\Python25
\;C:\Python30\;...
py3.0rc3's result:
C:\Python25\;C:\Tcl\bin;C:\oracle\product\10.2.0\db_1
\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\Program
Files\Borland\Delphi7\Bin;C:\Program Files\Borland\Delphi7
\Projects\Bpl\;C:\Program Files\Java\jdk1.7.0\bin;C:\Python25
\;C:\Python30\;...
you can see that python3.0 gets extra element "C:\Python25\",which is
first. Is it a bug or something? thanks.
----------
components: Library (Lib)
files: path_result.txt
messages: 76294
nosy: clive
severity: normal
status: open
title: os.getenv('PATH') return different result between 2.5 and 3.0rc3
versions: Python 3.0
Added file: http://bugs.python.org/file12116/path_result.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4402>
_______________________________________
From report at bugs.python.org Mon Nov 24 04:59:04 2008
From: report at bugs.python.org (August Mueller)
Date: Mon, 24 Nov 2008 03:59:04 +0000
Subject: [New-bugs-announce] [issue4403] regression from 2.6: smtplib.py
requiring ascii for sending messages
In-Reply-To: <1227499144.72.0.0111235228814.issue4403@psf.upfronthosting.co.za>
Message-ID: <1227499144.72.0.0111235228814.issue4403@psf.upfronthosting.co.za>
New submission from August Mueller <gus at flyingmeat.com>:
smtplib requires that messages being sent be in ascii, and throws an exception otherwise.
Python 2.6 doesn't require this. Here's the diff where it was introduced:
http://svn.python.org/view/python/branches/py3k/Lib/smtplib.py?rev=59102&r1=58495&r2=59102
Is there a good reason for this? I use python for a webstore, and send out emails for folks
with multibyte names (for instance, if a name has an umlaut).
Here's a code snippit + exception:
Python 3.0rc3 (r30rc3:67312, Nov 22 2008, 18:45:57)
[GCC 3.4.6 [FreeBSD] 20060305] on freebsd6
Type "help", "copyright", "credits" or "license" for more information.
>>> import smtplib
>>> server = smtplib.SMTP("localhost")
>>> server.sendmail("gus at flyingmeat.com", "gus at flyingmeat.com", "?mlaut")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/mu.org/home/gus/unix/python3/lib/python3.0/smtplib.py", line 713, in sendmail
(code,resp) = self.data(msg)
File "/home/mu.org/home/gus/unix/python3/lib/python3.0/smtplib.py", line 481, in data
self.send(q)
File "/home/mu.org/home/gus/unix/python3/lib/python3.0/smtplib.py", line 305, in send
s = s.encode("ascii")
UnicodeEncodeError: 'ascii' codec can't encode character '\xdc' in position 0: ordinal not in
range(128)
Is there a workaround or a new way of using it? I couldn't seem to find it.
Thanks!
----------
components: Library (Lib)
messages: 76295
nosy: ccgus
severity: normal
status: open
title: regression from 2.6: smtplib.py requiring ascii for sending messages
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4403>
_______________________________________
From martin at v.loewis.de Mon Nov 24 06:50:09 2008
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Mon, 24 Nov 2008 06:50:09 +0100
Subject: [New-bugs-announce] [issue4403] regression from 2.6: smtplib.py
requiring ascii for sending messages
In-Reply-To: <1227499144.72.0.0111235228814.issue4403@psf.upfronthosting.co.za>
References: <1227499144.72.0.0111235228814.issue4403@psf.upfronthosting.co.za>
Message-ID: <492A4091.8050800@v.loewis.de>
> Is there a good reason for this?
Most definitely. In Python 2.x, the string literal denotes
a byte string, whereas in 3.x, it is a character string.
It's not possible to send a character string directly over
the network; try encoding it.
It might be considered a bug that sendmail accepts a string
at all as long as the string only consists of ASCII characters;
it should reject such strings as well.
From report at bugs.python.org Mon Nov 24 08:00:56 2008
From: report at bugs.python.org (steve21)
Date: Mon, 24 Nov 2008 07:00:56 +0000
Subject: [New-bugs-announce] [issue4404] os.listdir() documentation error
In-Reply-To: <1227510056.52.0.380285272246.issue4404@psf.upfronthosting.co.za>
Message-ID: <1227510056.52.0.380285272246.issue4404@psf.upfronthosting.co.za>
New submission from steve21 <steve872929-bv at yahoo.com.au>:
The documentation entry for os.listdir(path) at
html docs at http://docs.python.org/dev/3.0/library/os.html#module-os
says:
"os.listdir(path)
Return a list containing the names of the entries in the directory.
The list is in arbitrary order. It does not include the special entries
. and .. even if they are present in the directory. Availability: Unix,
Windows.
This function can be called with a bytes or string argument. In the
bytes case, all filenames will be listed as returned by the underlying
API. In the string case, filenames will be decoded using the file system
encoding, and skipped if a decoding error occurs."
The problem is that nowhere it the above documentation does it describe
what the 'path' argument should be !
However, if I do
$ Python3.0
>>> import os
>>> help(os.listdir) # it does describe 'path'
Help on built-in function listdir in module posix:
listdir(...)
listdir(path) -> list_of_strings
Return a list containing the names of the entries in the directory.
path: path of directory to list
The list is in arbitrary order. It does not include the special
entries '.' and '..' even if they are present in the directory.
It looks like the html docs are missing some information and out of sync
with the module docs.
----------
assignee: georg.brandl
components: Documentation
messages: 76307
nosy: georg.brandl, steve21
severity: normal
status: open
title: os.listdir() documentation error
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4404>
_______________________________________
From report at bugs.python.org Mon Nov 24 10:02:06 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 24 Nov 2008 09:02:06 +0000
Subject: [New-bugs-announce] [issue4405] fix_metaclass broken
In-Reply-To: <1227517326.18.0.828990199239.issue4405@psf.upfronthosting.co.za>
Message-ID: <1227517326.18.0.828990199239.issue4405@psf.upfronthosting.co.za>
New submission from Martin v. L?wis <martin at v.loewis.de>:
When trying to run 2to3 on Django, I get a traceback
File "/tmp/py3/lib/python3.0/lib2to3/refactor.py", line 260, in
refactor_string
self.refactor_tree(tree, name)
File "/tmp/py3/lib/python3.0/lib2to3/refactor.py", line 299, in
refactor_tree
self.traverse_by(self.post_order, tree.post_order())
File "/tmp/py3/lib/python3.0/lib2to3/refactor.py", line 323, in
traverse_by
new = fixer.transform(node, results)
File "/tmp/py3/lib/python3.0/lib2to3/fixes/fix_metaclass.py", line
156, in transform
for suite, i, stmt in find_metas(node):
File "/tmp/py3/lib/python3.0/lib2to3/fixes/fix_metaclass.py", line
114, in find_metas
if leaf_node.value == '__metaclass__':
AttributeError: 'Node' object has no attribute 'value'
The smallest example reproducing this is
class Model(object):
__metaclass__ = ModelBase
save.alters_data = True
----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 76311
nosy: loewis
severity: normal
status: open
title: fix_metaclass broken
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4405>
_______________________________________
From report at bugs.python.org Mon Nov 24 10:14:39 2008
From: report at bugs.python.org (lion.guo)
Date: Mon, 24 Nov 2008 09:14:39 +0000
Subject: [New-bugs-announce] [issue4406] In Lib\tkinter\filedialog.py,
class Directory define loss a"_"
In-Reply-To: <1227518079.5.0.478868992951.issue4406@psf.upfronthosting.co.za>
Message-ID: <1227518079.5.0.478868992951.issue4406@psf.upfronthosting.co.za>
New submission from lion.guo <lion.guo at gmail.com>:
In Lib\tkinter\filedialog.py, class Directory
"class Directory(Dialog):"
should be
"class Directory(_Dialog):"
----------
components: Tests
messages: 76312
nosy: lion.guo
severity: normal
status: open
title: In Lib\tkinter\filedialog.py, class Directory define loss a"_"
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4406>
_______________________________________
From report at bugs.python.org Mon Nov 24 12:15:13 2008
From: report at bugs.python.org (Eric Devolder)
Date: Mon, 24 Nov 2008 11:15:13 +0000
Subject: [New-bugs-announce] [issue4407] Windows Installer Error 1722 when
opting for compilation at install time
In-Reply-To: <1227525313.94.0.0083340385005.issue4407@psf.upfronthosting.co.za>
Message-ID: <1227525313.94.0.0083340385005.issue4407@psf.upfronthosting.co.za>
New submission from Eric Devolder <eric.devolder at gmail.com>:
This error happens when opting in for compiling the scripts at
installation. (please note also that I did not selected "register
extension", but I don't think this has an impact).
Here is the text from event viewer:
Product: Python 3.0rc3 -- Error 1722. There is a problem with this
Windows Installer package. A program run as part of the setup did not
finish as expected. Contact your support personnel or package vendor.
Action CompilePyc, location: L:\Python30\python.exe, command: -Wi
"L:\Python30\Lib\compileall.py" -f -x
bad_coding|badsyntax|site-packages|py2_ "L:\Python30\Lib"
Running the command manually indeed crashes, because of pipe symbol
being interpretted at shell level, not Python.
Please find attached a patch on Tools\msi\msi.py that addresses the
problem (untested, I don't have VStudio )
----------
components: Installation
files: compileall_py.patch
keywords: patch
messages: 76318
nosy: keldonin
severity: normal
status: open
title: Windows Installer Error 1722 when opting for compilation at install time
versions: Python 3.0
Added file: http://bugs.python.org/file12119/compileall_py.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4407>
_______________________________________
From report at bugs.python.org Mon Nov 24 13:16:11 2008
From: report at bugs.python.org (Florian Weimer)
Date: Mon, 24 Nov 2008 12:16:11 +0000
Subject: [New-bugs-announce] [issue4408] re.compile(regexp).groups not
documented
In-Reply-To: <1227528971.48.0.179981852127.issue4408@psf.upfronthosting.co.za>
Message-ID: <1227528971.48.0.179981852127.issue4408@psf.upfronthosting.co.za>
New submission from Florian Weimer <fw at deneb.enyo.de>:
This does result in the expected result 2:
> re.compile('(.)(.)').groups
But as far as I can see, the groups property is missing from the HTML
documentation. Please clarify if this an internal interface, or a
documentation oversight.
----------
components: Regular Expressions
messages: 76321
nosy: fw
severity: normal
status: open
title: re.compile(regexp).groups not documented
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4408>
_______________________________________
From report at bugs.python.org Mon Nov 24 16:16:45 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 24 Nov 2008 15:16:45 +0000
Subject: [New-bugs-announce] [issue4409] Dangling asterisks in Python 3.0
subprocess docs
In-Reply-To: <18730.50503.956524.686132@montanaro-dyndns-org.local>
Message-ID: <18730.50503.956524.686132@montanaro-dyndns-org.local>
New submission from Skip Montanaro <skip at pobox.com>:
Georg,
I just noticed that there are asterisks in a couple places in the subprocess
module documentation which don't appear to have corresponding footnotes.
All the way at the bottom are subsections called
Replacing os.spawn*
Replacing os.popen*
I don't know what the '*' is supposed to mean, but in normal usage it would
tell the user there is a footnote which elaborates on something related to
that text. I don't see any such footnotes. Oh, wait a minute. You
probably mean for them to be wildcards. Hmmm... Probably not the best
usage. Can you find a different way to indicate that those examples refer
to a larger category of functions?
Skip
----------
messages: 76326
nosy: skip.montanaro
severity: normal
status: open
title: Dangling asterisks in Python 3.0 subprocess docs
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4409>
_______________________________________
From report at bugs.python.org Mon Nov 24 19:16:49 2008
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9?=)
Date: Mon, 24 Nov 2008 18:16:49 +0000
Subject: [New-bugs-announce] [issue4410] IDLE string problem in Run/Run
Module
In-Reply-To: <1227550609.93.0.240511987484.issue4410@psf.upfronthosting.co.za>
Message-ID: <1227550609.93.0.240511987484.issue4410@psf.upfronthosting.co.za>
New submission from Andr? <info at orlans-amo.be>:
Python 3.0 rc3 on Windows (Server 2003 US English)
The code with a string including a non ascii character:
s = 'ab?d'
print (s)
is returning correct result in console mode and when it's typed in the
IDLE Python Shell
But when executed from an IDLE editor window with Run/Run Module
it prints 5 characters instead of 4.
With more details, the code:
s = 'ab?d'
print (s)
for i in range(len(s)):
print(hex(ord(s[i])),end=' ')
gives in console mode:
ab?d
0x61 0x62 0xe7 0x64
but with Run/Run Module:
ab??d
0x61 0x62 0xc3 0xa7 0x64
----------
components: IDLE
messages: 76353
nosy: andre
severity: normal
status: open
title: IDLE string problem in Run/Run Module
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4410>
_______________________________________
From report at bugs.python.org Mon Nov 24 20:08:29 2008
From: report at bugs.python.org (Sebastian Wiesner)
Date: Mon, 24 Nov 2008 19:08:29 +0000
Subject: [New-bugs-announce] [issue4411] __mro__ documentation
In-Reply-To: <1227553709.92.0.112307623193.issue4411@psf.upfronthosting.co.za>
Message-ID: <1227553709.92.0.112307623193.issue4411@psf.upfronthosting.co.za>
New submission from Sebastian Wiesner <basti.wiesner at gmx.net>:
The documentation of Python 2.6 and 2.7 only mentions the class
attribute "__mro__" in ABC documentation and in Data model documentation
when explaining description invocation (see search results:
http://docs.python.org/dev/search.html?q=__mro__&check_keywords=yes&area=default)
Imho __mro__ lacks documentation in "Standard Type Hierachy", where
special attributes of fundamental data types are documented.
----------
assignee: georg.brandl
components: Documentation
messages: 76355
nosy: georg.brandl, lunar
severity: normal
status: open
title: __mro__ documentation
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4411>
_______________________________________
From report at bugs.python.org Tue Nov 25 01:39:49 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 00:39:49 +0000
Subject: [New-bugs-announce] [issue4412] Failure to test return value of
PyUnicode_AsUTF8String() for NULL
In-Reply-To: <1227573589.29.0.468760733343.issue4412@psf.upfronthosting.co.za>
Message-ID: <1227573589.29.0.468760733343.issue4412@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
/home/rxc92/project/Python-2.5.2/Parser/tokenizer.c
(translate_into_utf8) Line 573
The return value of PyUnicode_AsUTF8String() is never checked if it is NULL.
Reference:
http://www.python.org/doc/2.5.2/api/builtinCodecs.html#l2h-523
----------
components: None
messages: 76372
nosy: CWRU_Researcher1
severity: normal
status: open
title: Failure to test return value of PyUnicode_AsUTF8String() for NULL
type: resource usage
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4412>
_______________________________________
From report at bugs.python.org Tue Nov 25 01:42:39 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 00:42:39 +0000
Subject: [New-bugs-announce] [issue4413] Failure to check
PyUnicode_AsUTF8String() return value for NULL
In-Reply-To: <1227573759.51.0.712537159422.issue4413@psf.upfronthosting.co.za>
Message-ID: <1227573759.51.0.712537159422.issue4413@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
/home/rxc92/project/Python-2.5.2/Objects/unicodeobject.c(PyUnicodeUCS2_AsEncodedString)
Line 699
Failed to check PyUnicode_AsUTF8String() for returning NULL.
Referenced:
http://www.python.org/doc/2.5.2/api/builtinCodecs.html#l2h-523
----------
components: None
messages: 76373
nosy: CWRU_Researcher1
severity: normal
status: open
title: Failure to check PyUnicode_AsUTF8String() return value for NULL
type: resource usage
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4413>
_______________________________________
From report at bugs.python.org Tue Nov 25 01:50:30 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 00:50:30 +0000
Subject: [New-bugs-announce] [issue4414] Failure to check return value of
PyBool_FromLong for NULL
In-Reply-To: <1227574230.19.0.431218363165.issue4414@psf.upfronthosting.co.za>
Message-ID: <1227574230.19.0.431218363165.issue4414@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
/home/rxc92/project/Python-2.5.2/Objects/unicodeobject.c(unicode_istitle)
Line 5953
Failed to check that the return value of PyBool_FromLong is not NULL
Referenced:
http://www.python.org/doc/2.5.2/api/boolObjects.html#l2h-400
----------
components: None
messages: 76375
nosy: CWRU_Researcher1
severity: normal
status: open
title: Failure to check return value of PyBool_FromLong for NULL
type: resource usage
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4414>
_______________________________________
From report at bugs.python.org Tue Nov 25 02:01:35 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 01:01:35 +0000
Subject: [New-bugs-announce] [issue4415] Failure to check return value of
PyBool_FromLong for NULL
In-Reply-To: <1227574895.83.0.787217406035.issue4415@psf.upfronthosting.co.za>
Message-ID: <1227574895.83.0.787217406035.issue4415@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
/home/rxc92/project/Python-2.5.2/Python/import.c(imp_is_frozen)
Line 2740
Failed to check that the return value of PyBool_FromLong is not NULL
Referenced:
http://www.python.org/doc/2.5.2/api/boolObjects.html#l2h-400
----------
components: None
messages: 76376
nosy: CWRU_Researcher1
severity: normal
status: open
title: Failure to check return value of PyBool_FromLong for NULL
type: resource usage
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4415>
_______________________________________
From report at bugs.python.org Tue Nov 25 02:11:06 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 01:11:06 +0000
Subject: [New-bugs-announce] [issue4416] state_reset not called on 'state'
before sre_search invoked
In-Reply-To: <1227575466.25.0.165680108387.issue4416@psf.upfronthosting.co.za>
Message-ID: <1227575466.25.0.165680108387.issue4416@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
/home/rxc92/project/Python-2.5.2/Modules/_sre.c (pattern_search)
Line 2740
Elsewhere in the codebase, state_reset is called on the first parameter
of sre_search before sre_search is invoked. The does not occur here.
----------
components: None
messages: 76377
nosy: CWRU_Researcher1
severity: normal
status: open
title: state_reset not called on 'state' before sre_search invoked
type: performance
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4416>
_______________________________________
From report at bugs.python.org Tue Nov 25 02:15:05 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 01:15:05 +0000
Subject: [New-bugs-announce] [issue4417] PySequence_List is not checked for
NULL return value
In-Reply-To: <1227575705.99.0.0604113097847.issue4417@psf.upfronthosting.co.za>
Message-ID: <1227575705.99.0.0604113097847.issue4417@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
Python-2.5.2/Objects/abstract.c(PySequence_Fast)
Line 1611
PySequence_List is not checked for NULL return value
----------
messages: 76379
nosy: CWRU_Researcher1
severity: normal
status: open
title: PySequence_List is not checked for NULL return value
type: resource usage
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4417>
_______________________________________
From report at bugs.python.org Tue Nov 25 02:17:27 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 01:17:27 +0000
Subject: [New-bugs-announce] [issue4418] PyObject_CallObject is not checked
for NULL return value
In-Reply-To: <1227575847.41.0.657005379639.issue4418@psf.upfronthosting.co.za>
Message-ID: <1227575847.41.0.657005379639.issue4418@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
Python-2.5.2/Modules/_sre.c(PySequence_Fast)
Line 1963
PyObject_CallObject is not checked for NULL return value
----------
messages: 76380
nosy: CWRU_Researcher1
severity: normal
status: open
title: PyObject_CallObject is not checked for NULL return value
type: resource usage
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4418>
_______________________________________
From report at bugs.python.org Tue Nov 25 02:23:46 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 01:23:46 +0000
Subject: [New-bugs-announce] [issue4419] PyUnicode_DecodeUTF8 is not checked
for NULL return value
In-Reply-To: <1227576226.15.0.611175528294.issue4419@psf.upfronthosting.co.za>
Message-ID: <1227576226.15.0.611175528294.issue4419@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
Python-2.5.2/Objects/unicodeobject.c
Line 587
PyUnicode_DecodeUTF8 is not checked for NULL return value
----------
components: None
messages: 76382
nosy: CWRU_Researcher1
severity: normal
status: open
title: PyUnicode_DecodeUTF8 is not checked for NULL return value
type: resource usage
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4419>
_______________________________________
From report at bugs.python.org Tue Nov 25 02:26:39 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 01:26:39 +0000
Subject: [New-bugs-announce] [issue4420] PyUnicode_Decode is not checked for
NULL return value
In-Reply-To: <1227576399.41.0.804406467928.issue4420@psf.upfronthosting.co.za>
Message-ID: <1227576399.41.0.804406467928.issue4420@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
Python-2.5.2/Objects/unicodeobject.c(PyUnicodeUCS2_FromEncodedObject)
Line 567
PyUnicode_Decode is not checked for NULL return value
----------
components: None
messages: 76383
nosy: CWRU_Researcher1
severity: normal
status: open
title: PyUnicode_Decode is not checked for NULL return value
type: resource usage
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4420>
_______________________________________
From report at bugs.python.org Tue Nov 25 02:33:42 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 01:33:42 +0000
Subject: [New-bugs-announce] [issue4421] Failed to check 3rd Param of
PyArena_AddPyObject() to ensure it isn't NULL
In-Reply-To: <1227576822.65.0.0416412823573.issue4421@psf.upfronthosting.co.za>
Message-ID: <1227576822.65.0.0416412823573.issue4421@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
Python-2.5.2/Python/ast.c(new_identifier)
Line 52
Failed to check 3rd Param of PyArena_AddPyObject() to ensure it isn't NULL
----------
components: None
messages: 76384
nosy: CWRU_Researcher1
severity: normal
status: open
title: Failed to check 3rd Param of PyArena_AddPyObject() to ensure it isn't NULL
type: resource usage
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4421>
_______________________________________
From report at bugs.python.org Tue Nov 25 02:35:12 2008
From: report at bugs.python.org (Brian Szuter)
Date: Tue, 25 Nov 2008 01:35:12 +0000
Subject: [New-bugs-announce] [issue4422] Failed to check 3rd Param of
PyArena_AddPyObject() to ensure it isn't NULL
In-Reply-To: <1227576912.78.0.193917017995.issue4422@psf.upfronthosting.co.za>
Message-ID: <1227576912.78.0.193917017995.issue4422@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
Python-2.5.2/Python/ast.c(alias_for_import_name)
Line 2282, 2288
Failed to check 3rd Param of PyArena_AddPyObject() to ensure it isn't NULL
----------
components: None
messages: 76385
nosy: CWRU_Researcher1
severity: normal
status: open
title: Failed to check 3rd Param of PyArena_AddPyObject() to ensure it isn't NULL
type: resource usage
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4422>
_______________________________________
From report at bugs.python.org Tue Nov 25 04:35:00 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 25 Nov 2008 03:35:00 +0000
Subject: [New-bugs-announce] [issue4423] 2to3 replaces "arbitrary" variables
In-Reply-To: <1227584100.69.0.467300606642.issue4423@psf.upfronthosting.co.za>
Message-ID: <1227584100.69.0.467300606642.issue4423@psf.upfronthosting.co.za>
New submission from Martin v. L?wis <martin at v.loewis.de>:
In 2to3 (from the py3k branch, as of r67372) translates the fragment
def f():
commands = foo()
commands.sort()
to
def f():
commands = foo()
subprocess.sort()
----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 76394
nosy: loewis
severity: normal
status: open
title: 2to3 replaces "arbitrary" variables
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4423>
_______________________________________
From report at bugs.python.org Tue Nov 25 05:39:24 2008
From: report at bugs.python.org (Alex)
Date: Tue, 25 Nov 2008 04:39:24 +0000
Subject: [New-bugs-announce] [issue4424] Add support for a cmp,
or key argument to heapq functions.
In-Reply-To: <1227587964.05.0.309336873132.issue4424@psf.upfronthosting.co.za>
Message-ID: <1227587964.05.0.309336873132.issue4424@psf.upfronthosting.co.za>
New submission from Alex <alex.gaynor at gmail.com>:
Currently the heapq module can only really be used if your data has it's
own ordering defined. There is no way to do a custom ordering. From my
cursory review of the code it looks like some of the lower level
functions actually take these kwargs, but the public interface does not.
----------
components: Library (Lib)
messages: 76398
nosy: alex
severity: normal
status: open
title: Add support for a cmp, or key argument to heapq functions.
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4424>
_______________________________________
From report at bugs.python.org Tue Nov 25 12:03:53 2008
From: report at bugs.python.org (Nick Barnes)
Date: Tue, 25 Nov 2008 11:03:53 +0000
Subject: [New-bugs-announce] [issue4425] UTF7 encoding of slash (character
47) is incorrect
In-Reply-To: <1227611033.17.0.24847692202.issue4425@psf.upfronthosting.co.za>
Message-ID: <1227611033.17.0.24847692202.issue4425@psf.upfronthosting.co.za>
New submission from Nick Barnes <Nick.Barnes at pobox.com>:
'/'.encode('utf7') returns '+AC8-'. It should return '/'. See RFC 2152.
'/'.decode('utf7') raises an exception (this is a special case of a
general problem with UTF-7 decoding, which I will report as a separate bug).
----------
components: Unicode
messages: 76404
nosy: Nick Barnes
severity: normal
status: open
title: UTF7 encoding of slash (character 47) is incorrect
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4425>
_______________________________________
From report at bugs.python.org Tue Nov 25 12:11:56 2008
From: report at bugs.python.org (Nick Barnes)
Date: Tue, 25 Nov 2008 11:11:56 +0000
Subject: [New-bugs-announce] [issue4426] UTF7 decoding is far too strict
In-Reply-To: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Message-ID: <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
New submission from Nick Barnes <Nick.Barnes at pobox.com>:
UTF-7 decoding raises an exception for any character not in the RFC2152
"Set D" (directly encoded characters). In particular, it raises an
exception for characters in "Set O" (optional direct characters), such
as < = > [ ] @ etc. These characters can legitimately appear in
UTF-7-encoded text, and should be decoded (as themselves). As it is,
the UTF-7 decoder can't reliably be used to decode any UTF-7 text other
than that encoded by Python's own UTF-7 encoder.
Looking at the source of unicodeobject.c, the call to the SPECIAL macro
on line 1009 has hardcoded second and third arguments of zero. Maybe
changing the second argument to 1 would fix this. Maybe.
----------
components: Unicode
messages: 76405
nosy: Nick Barnes
severity: normal
status: open
title: UTF7 decoding is far too strict
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4426>
_______________________________________
From report at bugs.python.org Tue Nov 25 12:41:05 2008
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 25 Nov 2008 11:41:05 +0000
Subject: [New-bugs-announce] [issue4427] Docs for 'y' Py_BuildValue tag are
wrong
Message-ID: <1227613265.45.0.0537998980121.issue4427@psf.upfronthosting.co.za>
Changes by Thomas Heller <theller at ctypes.org>:
----------
assignee: georg.brandl
components: Documentation
files: doc.patch
keywords: patch, patch
nosy: georg.brandl, theller
severity: normal
stage: patch review
status: open
title: Docs for 'y' Py_BuildValue tag are wrong
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12128/doc.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4427>
_______________________________________
From report at bugs.python.org Tue Nov 25 13:35:00 2008
From: report at bugs.python.org (David M. Beazley)
Date: Tue, 25 Nov 2008 12:35:00 +0000
Subject: [New-bugs-announce] [issue4428] io.BufferedWriter does not observe
buffer size limits
In-Reply-To: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
Message-ID: <1227616500.52.0.902847325707.issue4428@psf.upfronthosting.co.za>
New submission from David M. Beazley <beazley at users.sourceforge.net>:
The Buffered I/O interface in the io module has the user specify buffer
limits such as size and max_buffer_size. The first limit (size) is
easy to understand as a buffering threshold at which writes will occur.
However, no apparent attempt is made to strictly limit the internal
buffer size to max_buffer_size.
In BuffererWriter.write(), one of the first operations is
self._write_buf.extend(b)
which simply extends the buffer by the full data being written. If b
happens to be a large string (e.g., megabytes or even the entire
contents of a big file), then the internal I/O buffer makes a complete
copy of the data, effectively doubling the memory requirements for
carrying out the write operation.
I suppose most programmers might not notice given that everyone has
gigabytes of RAM these days, but you certainly don't see this kind of
buffering behavior in the operating system kernel or in the C library.
Some patch suggestions (details left to the maintainers of this module):
1. Don't extend self._write_buf by more than the max_buffer_size.
fragment = b[:self.max_buffer_size - len(self._write_buf)]
self._write_buf.extend(fragment)
2. For large blocking writes, simply carry out the remaining I/O
operations in the write() method instead of in the _flush_locked()
method. Try to use the original input data b as the data
source instead of making copies of it. And if you have to copy
the data, don't do it all at once.
----------
components: Library (Lib)
messages: 76408
nosy: beazley
severity: normal
status: open
title: io.BufferedWriter does not observe buffer size limits
type: resource usage
versions: Python 2.6, Python 2.7, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4428>
_______________________________________
From report at bugs.python.org Tue Nov 25 13:43:12 2008
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 25 Nov 2008 12:43:12 +0000
Subject: [New-bugs-announce] [issue4429] ctypes.FormatError raises when the
string to return contains non-ascii characters
In-Reply-To: <1227616992.36.0.883243032558.issue4429@psf.upfronthosting.co.za>
Message-ID: <1227616992.36.0.883243032558.issue4429@psf.upfronthosting.co.za>
New submission from Thomas Heller <theller at ctypes.org>:
ctypes raises UnicodeDecodeError in german windows (it should print
'Unzul?ssige Funktion'):
>>> from ctypes import FormatError
[46681 refs]
>>> FormatError(1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 5-7:
invalid data
[46742 refs]
>>>
----------
assignee: theller
components: ctypes
messages: 76411
nosy: theller
priority: release blocker
severity: normal
status: open
title: ctypes.FormatError raises when the string to return contains non-ascii characters
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4429>
_______________________________________
From report at bugs.python.org Tue Nov 25 17:36:42 2008
From: report at bugs.python.org (sil)
Date: Tue, 25 Nov 2008 16:36:42 +0000
Subject: [New-bugs-announce] [issue4430] time.strptime does not allow same
format directive twice
In-Reply-To: <1227631002.53.0.398407086497.issue4430@psf.upfronthosting.co.za>
Message-ID: <1227631002.53.0.398407086497.issue4430@psf.upfronthosting.co.za>
New submission from sil <sil-python at kryogenix.org>:
$ python -c "import time; print time.strptime('25/11/2008
25/11/2008','%d/%m/%y %d/%m/%y')"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python2.5/_strptime.py", line 311, in strptime
format_regex = _TimeRE_cache.compile(format)
File "/usr/lib/python2.5/_strptime.py", line 267, in compile
return re_compile(self.pattern(format), IGNORECASE)
File "/usr/lib/python2.5/re.py", line 188, in compile
return _compile(pattern, flags)
File "/usr/lib/python2.5/re.py", line 241, in _compile
raise error, v # invalid expression
sre_constants.error: redefinition of group name 'd' as group 4; was group 1
If a format directive is repeated in time.strptime's format string, it
throws an error and should not do so. Subversion, for example, repeats
date parts in its svn log output ("2008-09-26 16:20:59 +0100 (Fri, 26
Sep 2008)"), which repeats both %d (day) and %y (year).
----------
messages: 76417
nosy: sil
severity: normal
status: open
title: time.strptime does not allow same format directive twice
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4430>
_______________________________________
From report at bugs.python.org Tue Nov 25 21:16:34 2008
From: report at bugs.python.org (David Schnur)
Date: Tue, 25 Nov 2008 20:16:34 +0000
Subject: [New-bugs-announce] [issue4431] Distutils MSVC doesn't create
manifest file (with fix)
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
New submission from David Schnur <david.schnur at dartware.com>:
This is my first time submitting an issue; sorry if I am doing this
wrong. While attempting to build/install PyOpenSSL on Windows / MSVC,
the mt.exe step failed because it could not find the manifest file that
it was attempting to embed in crypto.pyd. The problem was that link.exe
was not creating the manifest.
The reason why is that distutils only passes link.exe the
/MANIFESTFILE:filename parameter. This tells it where to output the
manifest, but not to actually create the manifest (see http://msdn.microsoft.com/en-us/library/fft52235(VS.80).aspx). You'd
think link could figure out that, if you use /MANIFESTFILE, you want a
manifest, but I guess not ;)
My solution was to add this line to distutils/msvc9compiler.py:
ld_args.append('/MANIFEST')
Right beneath the existing line:
ld_args.append('/MANIFESTFILE:' + temp_manifest)
Hope that helps
----------
components: Distutils
messages: 76424
nosy: dschnur
severity: normal
status: open
title: Distutils MSVC doesn't create manifest file (with fix)
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________
From report at bugs.python.org Wed Nov 26 02:22:24 2008
From: report at bugs.python.org (LZ)
Date: Wed, 26 Nov 2008 01:22:24 +0000
Subject: [New-bugs-announce] [issue4432] IDLE.app (Mac) File Menu MIssing
Options
In-Reply-To: <1227662544.21.0.925756353896.issue4432@psf.upfronthosting.co.za>
Message-ID: <1227662544.21.0.925756353896.issue4432@psf.upfronthosting.co.za>
New submission from LZ <zullil at lafayette.edu>:
Just compiled and installed 3.0rc3 configured with --enable-framework
I can start IDLE.app in /Applications/Python 3.0, but the only option in
that application's File menu is a list of recent files. What about Open?
What about Save? etc
----------
components: IDLE
messages: 76443
nosy: LZ
severity: normal
status: open
title: IDLE.app (Mac) File Menu MIssing Options
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4432>
_______________________________________
From report at bugs.python.org Wed Nov 26 09:36:06 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 26 Nov 2008 08:36:06 +0000
Subject: [New-bugs-announce] [issue4433] _ctypes.COMError crash
In-Reply-To: <1227688566.82.0.912024341466.issue4433@psf.upfronthosting.co.za>
Message-ID: <1227688566.82.0.912024341466.issue4433@psf.upfronthosting.co.za>
New submission from Thomas Heller <theller at ctypes.org>:
The following code, which only works on Windows, crashes with an access
violation somewhere in the garbage collector in a debug build:
>>> import _ctypes
[43470 refs]
>>> _ctypes.COMError(1, 2, 3)
The problem is that the PyComError_Type's tp_flags contains
Py_TPFLAGS_HAVE_GC although the tp_traverse slot is NULL.
The attached patch removes the Py_TPFLAGS_HAVE_GC which is not necessary
at all because a PyComError_Type instance (normally) only contains
simple objects (strings, numbers, None, and a tuple of strings, numbers,
and None), so no reference cycles should be possible.
----------
assignee: theller
components: ctypes
files: ctypes.patch
keywords: needs review, patch, patch
messages: 76451
nosy: theller
priority: release blocker
severity: normal
status: open
title: _ctypes.COMError crash
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file12133/ctypes.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4433>
_______________________________________
From report at bugs.python.org Wed Nov 26 10:13:39 2008
From: report at bugs.python.org (rb)
Date: Wed, 26 Nov 2008 09:13:39 +0000
Subject: [New-bugs-announce] [issue4434] Embedding into a shared library
fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
New submission from rb <rb-oss-1 at justgohome.co.uk>:
Python cannot be embedded in shared library due to dependency problems
with lib-dynload.
I am implementing a shared library (in C) that implements a specific API
as a dynamically loadable plugin to an application. To implement this
library, I am calling out to Python via the C API.
When my code tries to load a Python module, it fails. This is because
lib-dynload/time.so (for example) cannot resolve symbols that are in
libpython2.5.so because it never looks there.
In this test case I'm trying to import "time", but it seems to fail on
other modules too - presumably anything that is in lib-dynload. It also
fails if I import a pure Python module that then tries to import time.
The error produced is: ImportError:
/usr/lib/python2.5/lib-dynload/time.so: undefined symbol: PyExc_ValueError
>From LD_DEBUG:
29682:file=/usr/lib/python2.5/lib-dynload/time.so [0]; needed by
/usr/lib/libpython2.5.so.1.0 [0]
...
29682:relocation processing: /usr/lib/python2.5/lib-dynload/time.so
29682:symbol=PyExc_ValueError; lookup in file=./myprog [0]
29682:symbol=PyExc_ValueError; lookup in file=/lib/libdl.so.2 [0]
29682:symbol=PyExc_ValueError; lookup in file=/lib/libc.so.6 [0]
29682:symbol=PyExc_ValueError; lookup in
file=/lib64/ld-linux-x86-64.so.2 [0]
29682:symbol=PyExc_ValueError; lookup in
file=/usr/lib/python2.5/lib-dynload/time.so [0]
29682:symbol=PyExc_ValueError; lookup in file=/lib/libm.so.6 [0]
29682:symbol=PyExc_ValueError; lookup in file=/lib/libpthread.so.0 [0]
29682:symbol=PyExc_ValueError; lookup in file=/lib/libc.so.6 [0]
29682:symbol=PyExc_ValueError; lookup in
file=/lib64/ld-linux-x86-64.so.2 [0]
29682:/usr/lib/python2.5/lib-dynload/time.so: error: symbol lookup
error:
undefined symbol: PyExc_ValueError (fatal)
$ nm -D /usr/lib/libpython2.5.so.1|grep PyExc_ValueError
000000000033a7e0 D PyExc_ValueError
$ ldd /usr/lib/python2.5/lib-dynload/time.so
libm.so.6 => /lib/libm.so.6 (0x00002afe014c9000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002afe0174a000)
libc.so.6 => /lib/libc.so.6 (0x00002afe01967000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
I am told that the problem is that lib-dynload/*.so should depend on
libpython2.5.so.1.
Test case attached. mylib.c is the library that I'm implementing reduced
to the problem case. myprog.c is a stub program that loads mylib.c to
demonstrate the problem. The "real" myprog would be any third-party
application that I have no control over that expects to be able to
dlopen() mylib.so and call functions within it.
I have been given the following workaround: in mylib.c, before
PyInitialize() I can call dlopen("libpython2.5.so", RTLD_LAZY |
RTLD_GLOBAL);
This works, but I believe that lib-dynload/*.so should depend on
libpython2.5.so.1 so this hack should not be necessary.
I am using Ubuntu 8.04 with Python version 2.5.2-2ubuntu4.1.
----------
components: Library (Lib)
files: mylib.c
messages: 76454
nosy: rb
severity: normal
status: open
title: Embedding into a shared library fails
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file12134/mylib.c
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4434>
_______________________________________
From report at bugs.python.org Wed Nov 26 10:20:35 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Wed, 26 Nov 2008 09:20:35 +0000
Subject: [New-bugs-announce] [issue4435] Sphinx does not show failed
doctests in quiet mode
In-Reply-To: <1227691235.13.0.763520768033.issue4435@psf.upfronthosting.co.za>
Message-ID: <1227691235.13.0.763520768033.issue4435@psf.upfronthosting.co.za>
New submission from Robert Schuppenies <robert.schuppenies at gmail.com>:
Sphinx does not show failed doctests when run in quiet mode. Any output
from the tests seems to be suppressed. The same applies to the linkckeck
builder.
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 76455
nosy: georg.brandl, schuppenies
severity: normal
status: open
title: Sphinx does not show failed doctests in quiet mode
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4435>
_______________________________________
From report at bugs.python.org Wed Nov 26 10:42:15 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Wed, 26 Nov 2008 09:42:15 +0000
Subject: [New-bugs-announce] [issue4436] Sphinx latex writer crashes when
encountering deep section levels
In-Reply-To: <1227692535.17.0.165619686798.issue4436@psf.upfronthosting.co.za>
Message-ID: <1227692535.17.0.165619686798.issue4436@psf.upfronthosting.co.za>
New submission from Robert Schuppenies <robert.schuppenies at gmail.com>:
The Sphinx latex writer crashes if a documentation has more than 7
levels in a section hierarchy. The LaTeXTranslator class defines 7
section names, each corresponding to a level. If a deeper level is
encountered, no appropriate section name can be found:
File "[..]/svn/doctools/sphinx/latexwriter.py", line 348, in visit_title
print "self.sectionnames", self.sectionnames[self.sectionlevel]
IndexError: list index out of range
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 76456
nosy: georg.brandl, schuppenies
severity: normal
status: open
title: Sphinx latex writer crashes when encountering deep section levels
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4436>
_______________________________________
From report at bugs.python.org Wed Nov 26 11:43:59 2008
From: report at bugs.python.org (Francois Grieu)
Date: Wed, 26 Nov 2008 10:43:59 +0000
Subject: [New-bugs-announce] [issue4437] Windows 32-bit installer crash on
"cancel" in "advanced" settings
In-Reply-To: <1227696239.72.0.87378964191.issue4437@psf.upfronthosting.co.za>
Message-ID: <1227696239.72.0.87378964191.issue4437@psf.upfronthosting.co.za>
New submission from Francois Grieu <fgrieu at francenet.fr>:
On an Windows XP 32-bit system without Python installed
- launch python-2.6.msi (md5 6c62c123d248a48dccbaa4d3edc12680)
- click "next >" "next >" "advanced" "cancel" "yes"
- msiexex.exe crashes (repeatable).
Installation works fine if one do not press "advanced", or press
"finish" instead of "cancel".
----------
components: Installation
messages: 76459
nosy: fgrieu
severity: normal
status: open
title: Windows 32-bit installer crash on "cancel" in "advanced" settings
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4437>
_______________________________________
From report at bugs.python.org Wed Nov 26 12:58:39 2008
From: report at bugs.python.org (=?utf-8?q?Mart_S=C3=B5mermaa?=)
Date: Wed, 26 Nov 2008 11:58:39 +0000
Subject: [New-bugs-announce] [issue4438] Add an easy way to __import___
submodules
In-Reply-To: <1227700719.4.0.771610572152.issue4438@psf.upfronthosting.co.za>
Message-ID: <1227700719.4.0.771610572152.issue4438@psf.upfronthosting.co.za>
New submission from Mart S?mermaa <mrts at mrts.pri.ee>:
The need to dynamically import module foo given a module name string
'bar.baz.foo' is quite common.
Quite often, the hack described in http://bugs.python.org/issue2090 is
used (see e.g. the Google code results linked from the issue).
Quoting Brett Cannon from the issue:
"I plan to add a much simpler API to the imp module for people to use
directly so that these abuses don't continue."
Although there are reasonable workarounds, let the current ticket be a
remainder for Brett that his plan is indeed needed.
Perhaps the easiest thing to do would be to add yet another argument,
e.g. 'toplevel', to __import__, such that:
>>> __import__('imprt.foo.foo') # toplevel=True by default
<module 'imprt' from 'imprt/__init__.pyc'>
>>> __import__('imprt.foo.foo', toplevel=False)
<module 'imprt.foo.foo' from 'imprt/foo/foo.pyc'>
The latter can currently be achieved by
>>> __import__('imprt.foo.foo', {}, {}, ['foo'])
<module 'imprt.foo.foo' from 'imprt/foo/foo.pyc'>
which is cumbersome if the module name is given in a string, resulting
in unnecessarily complex code:
modname = "imprt.foo.foo"
>>> __import__(modname, {}, {}, [modname.rsplit(".", 1)[-1]])
<module 'imprt.foo.foo' from 'imprt/foo/foo.pyc'>
----------
components: Interpreter Core, Library (Lib)
messages: 76460
nosy: mrts
severity: normal
status: open
title: Add an easy way to __import___ submodules
type: feature request
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4438>
_______________________________________
From report at bugs.python.org Wed Nov 26 14:48:45 2008
From: report at bugs.python.org (olt)
Date: Wed, 26 Nov 2008 13:48:45 +0000
Subject: [New-bugs-announce] [issue4439] Typo in sqlite3 documentation.
In-Reply-To: <1227707325.32.0.287785933379.issue4439@psf.upfronthosting.co.za>
Message-ID: <1227707325.32.0.287785933379.issue4439@psf.upfronthosting.co.za>
New submission from olt <olt at bogosoft.com>:
There is a small typo in the possible Connection.isolation_level
http://docs.python.org/library/sqlite3.html#connection-objects
Its EXCLUSIVE not EXLUSIVE.
----------
components: Distutils
messages: 76465
nosy: olt
severity: normal
status: open
title: Typo in sqlite3 documentation.
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4439>
_______________________________________
From report at bugs.python.org Wed Nov 26 16:00:51 2008
From: report at bugs.python.org (Marcin Bachry)
Date: Wed, 26 Nov 2008 15:00:51 +0000
Subject: [New-bugs-announce] [issue4440] "sort" command doesn't work in
pstats if run interactively
In-Reply-To: <1227711651.41.0.519645038553.issue4440@psf.upfronthosting.co.za>
Message-ID: <1227711651.41.0.519645038553.issue4440@psf.upfronthosting.co.za>
New submission from Marcin Bachry <hegel666 at gmail.com>:
Sort command in Python's 3.0 pstats doesn't accept any valid argument
and views help all the time:
$ python3.0 -m pstats pstats
Welcome to the profile statistics browser.
% sort cumulative
Valid sort keys (unique prefixes are accepted):
stdname -- standard name
nfl -- name/file/line
pcalls -- call count
file -- file name
calls -- call count
time -- internal time
line -- line number
cumulative -- cumulative time
module -- file name
name -- function name
%
----------
components: Library (Lib)
files: pstats-fix.diff
keywords: patch
messages: 76467
nosy: marcin.bachry
severity: normal
status: open
title: "sort" command doesn't work in pstats if run interactively
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12137/pstats-fix.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4440>
_______________________________________
From report at bugs.python.org Wed Nov 26 17:21:50 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 26 Nov 2008 16:21:50 +0000
Subject: [New-bugs-announce] [issue4441] Improve os open flag options doc
In-Reply-To: <1227716510.76.0.255210544694.issue4441@psf.upfronthosting.co.za>
Message-ID: <1227716510.76.0.255210544694.issue4441@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
os module doc, File Descriptor Operations, at end.
Suggestions:
1. Replace
"The following data items are available for use in constructing the
flags parameter to the open() function."
with
"The following data items are options for the flag argument to the
open() function. These can be combined using the bitwise OR operator |."
(and remove the redundant text from the block headings -- see below).
2. In the next sentence, replace 'will not be' with 'are not'.
3. The next sentence ends with 'consult open(2).' I presume this refers
to unix manual section on the open system call. This is cryptic and
useless to many Windows users. Where are descriptions for flags valid
on Windows?
4. Block captions: remove repeated text and move availability note above
rather than below the block. 'Available on Unix and Windows', 'Available
on Unix only', 'Available on Windows only', 'Gnu extensions....'.
5. The items in the fifth block are *not* open() options. The caption
should instead be an un-indented introductory sentence before the block.
"The following data items are parameters to the lseek() function. ..."
----------
assignee: georg.brandl
components: Documentation
messages: 76471
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Improve os open flag options doc
versions: Python 2.7, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4441>
_______________________________________
From report at bugs.python.org Wed Nov 26 18:08:02 2008
From: report at bugs.python.org (Chris Withers)
Date: Wed, 26 Nov 2008 17:08:02 +0000
Subject: [New-bugs-announce] [issue4442] datetime not subclassable in the
usual way
In-Reply-To: <1227719282.37.0.890069433685.issue4442@psf.upfronthosting.co.za>
Message-ID: <1227719282.37.0.890069433685.issue4442@psf.upfronthosting.co.za>
New submission from Chris Withers <chris at simplistix.co.uk>:
>>> from datetime import datetime
>>> class defaultdatetime(datetime):
... defaults=(2001,1,1)
... def __init__(self,*args):
... if not args:
... args = self.defaults
... datetime.__init__(self,*args)
...
>>> defaultdatetime()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: function takes at least 3 arguments (0 given)
----------
components: Library (Lib)
messages: 76473
nosy: cjw296
severity: normal
status: open
title: datetime not subclassable in the usual way
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4442>
_______________________________________
From report at bugs.python.org Wed Nov 26 20:43:34 2008
From: report at bugs.python.org (LuisC)
Date: Wed, 26 Nov 2008 19:43:34 +0000
Subject: [New-bugs-announce] [issue4443] Python/pystate.c:561 :PyGILState:
The assertion 'autoInterpreterState' has failed
In-Reply-To: <1227728614.19.0.877274035205.issue4443@psf.upfronthosting.co.za>
Message-ID: <1227728614.19.0.877274035205.issue4443@psf.upfronthosting.co.za>
New submission from LuisC <luis.carrion at tcs.com>:
The project goal is to incorporate the functionality of interaction of
the excel application (gnumeric) with the XO's journal. All the
activities needs to register any change in that datastore (save and
open files are made throw it).
In order to apply this option, we need to call some python code from
the implementation of the worksheet in C code. This is called embedded
python in C. The steps followed to accomplish this goal came from the
OLPC site recomendations, in wiki.laptop.org. The python script for the
interaction with the journal's datastore can be found in here:
http://wiki.laptop.org/go/Copy_to_and_from_the_Journal
The changes in the gnumeric code are basically in the workbook-view.c
and main-application.c to handle the open and save options. In the main-
application.c the method gui_file_copy_from_journal uses the python
api/c to make the call to the journal script. after this method and
during the open of the file, an exception rises. Although we are not
sure, we believe it has to do with the closure of the python enviroment
after the finalize call. We need to erase this exception or may be just
handle it.
The error running in the XO is:
gnumeric: Python/pystate.c:561 :PyGILState: The
assertion 'autoInterpreterState' has failed
The configuration of the XO where we are getting the exception is:
Python 2.5 (r25:51908, Oct 19 2007, 09:47:40) [gcc 4.1.2 20070925 (Red
Hat 4.1.2-27)] on linux2
Any help is greatly appreciated!!!
----------
components: Interpreter Core
messages: 76484
nosy: barry, brett.cannon, doerwalter, gvanrossum, lcarrionr, lemburg, mwh
severity: normal
status: open
title: Python/pystate.c:561 :PyGILState: The assertion 'autoInterpreterState' has failed
type: resource usage
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4443>
_______________________________________
From report at bugs.python.org Thu Nov 27 10:50:00 2008
From: report at bugs.python.org (David Leonard)
Date: Thu, 27 Nov 2008 09:50:00 +0000
Subject: [New-bugs-announce] [issue4444] unittest - use contexts to assert
exceptions
In-Reply-To: <1227779400.76.0.0502987149884.issue4444@psf.upfronthosting.co.za>
Message-ID: <1227779400.76.0.0502987149884.issue4444@psf.upfronthosting.co.za>
New submission from David Leonard <d+python at adaptive-enterprises.com>:
Patch to allow unit tests to test for exceptions through a 'with'
statement. Resulting (failing) test would look like this:
import unittest
class T(unittest.TestCase):
def runTest(self):
with self.assertRaises(KeyError):
raise ValueError
This saves having to put exception raising tests into a try/except
block, which is cool. And by cool I mean totally sweet.
----------
components: Library (Lib)
files: unittest.patch
keywords: patch
messages: 76492
nosy: dleonard0
severity: normal
status: open
title: unittest - use contexts to assert exceptions
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file12138/unittest.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4444>
_______________________________________
From report at bugs.python.org Thu Nov 27 13:15:01 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 27 Nov 2008 12:15:01 +0000
Subject: [New-bugs-announce] [issue4445] String allocations waste 3 bytes of
memory on average.
In-Reply-To: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za>
Message-ID: <1227788101.62.0.102470807499.issue4445@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
There are a number of places in Objects/stringobject.c where memory is
allocated for a string of length n using:
PyObject_MALLOC(sizeof(PyStringObject) + n)
On my computer (OS X 10.5.5/Intel), and, I suspect, on most common
platforms, the PyStringObject struct is going to contain some number of
bytes (probably 3) of trailing padding; the result is that the
PyObject_MALLOC call above asks for 3 more bytes than are necessary, and
on average the Python interpreter will waste 3 bytes of memory per string
allocation. Is there any reason not to replace these calls with:
PyObject_MALLOC(offsetof(PyStringObject, ob_sval) + n + 1)
instead?
Patch attached.
----------
components: Interpreter Core
files: string_alloc.patch
keywords: patch
messages: 76495
nosy: marketdickinson
severity: normal
status: open
title: String allocations waste 3 bytes of memory on average.
type: performance
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file12140/string_alloc.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4445>
_______________________________________
From report at bugs.python.org Thu Nov 27 14:50:39 2008
From: report at bugs.python.org (Simon Cross)
Date: Thu, 27 Nov 2008 13:50:39 +0000
Subject: [New-bugs-announce] [issue4446] Distutils Metadata Documentation
Missing "platforms" Keyword
In-Reply-To: <1227793839.56.0.207871188628.issue4446@psf.upfronthosting.co.za>
Message-ID: <1227793839.56.0.207871188628.issue4446@psf.upfronthosting.co.za>
New submission from Simon Cross <hodgestar at gmail.com>:
The section on Additional meta-data in Doc/distutils/setupscript.rst is
missing any reference to the setup() "platforms" keyword. I've attached
a patch which fills in the basics but there are some outstanding questions:
- Does note (4) about backwards compatibility with earlier versions of
Python apply?
- What strings should be used to describe each platform? Perhaps any
final element of an "Operating System ::" trove classifier?
- Given that we have the classifiers, is the "platforms" keyword
actually needed? Perhaps the docs should just mark it as deprecated? We
would then maybe need to change distutils to populate the platforms key
in PKG-INFO from the classifiers?
----------
assignee: georg.brandl
components: Documentation
files: distutils-platforms-keyword-documentation.diff
keywords: patch
messages: 76499
nosy: georg.brandl, hodgestar
severity: normal
status: open
title: Distutils Metadata Documentation Missing "platforms" Keyword
versions: Python 2.5, Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12142/distutils-platforms-keyword-documentation.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4446>
_______________________________________
From report at bugs.python.org Thu Nov 27 18:35:02 2008
From: report at bugs.python.org (David M. Beazley)
Date: Thu, 27 Nov 2008 17:35:02 +0000
Subject: [New-bugs-announce] [issue4447] exec inside a function
In-Reply-To: <1227807302.43.0.654606733072.issue4447@psf.upfronthosting.co.za>
Message-ID: <1227807302.43.0.654606733072.issue4447@psf.upfronthosting.co.za>
New submission from David M. Beazley <beazley at users.sourceforge.net>:
Is the following code valid Python 3 or not?
def foo():
x = 1
exec("x = 42")
print(x) # Prints 1 (exec has no effect)
I know there are a variety of issues surrounding exec(), function
bodies, and other matters. Just wondering if this sort of thing is now
forbidden or not.
----------
components: Interpreter Core
messages: 76508
nosy: beazley
severity: normal
status: open
title: exec inside a function
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4447>
_______________________________________
From report at bugs.python.org Thu Nov 27 21:57:11 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 27 Nov 2008 20:57:11 +0000
Subject: [New-bugs-announce] [issue4448] should socket readline() use
default_bufsize instead of _rbufsize?
In-Reply-To: <1227819431.06.0.748604307582.issue4448@psf.upfronthosting.co.za>
Message-ID: <1227819431.06.0.748604307582.issue4448@psf.upfronthosting.co.za>
New submission from Gregory P. Smith <greg at krypto.org>:
....
>From Kristj?n Valur J?nsson (kristjan at ccpgames.com) on python-dev:
http://mail.python.org/pipermail/python-dev/2008-November/083724.html
....
I came across this in socket.c:
# _rbufsize is the suggested recv buffer size. It is *strictly*
# obeyed within readline() for recv calls. If it is larger than
# default_bufsize it will be used for recv calls within read().
What I worry about is the readline() case. Is there a reason why we
want to strictly obey it for that function? Note that in the
documentation for _fileobject.read() it says:
# Use max, disallow tiny reads in a loop as they are very
inefficient.
The same argument surely applies for readline().
The reason I am fretting about this is that httplib.py (and therefore
xmlrpclib.py) specify bufsize=0 when createing their socket fileobjects,
presumably to make sure that write() operations are not buffered but
flushed immediately. But this has the side effect of setting the
_rbufsize to 1, and so readline() calls become very slow.
I suggest that readline() be made to use at least defaultbufsize, like
read(). Any thoughts?
----------
assignee: gregory.p.smith
messages: 76516
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: should socket readline() use default_bufsize instead of _rbufsize?
type: performance
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4448>
_______________________________________
From report at bugs.python.org Fri Nov 28 12:17:05 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 28 Nov 2008 11:17:05 +0000
Subject: [New-bugs-announce] [issue4449] AssertionError in
Doc/includes/mp_benchmarks.py
In-Reply-To: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za>
Message-ID: <1227871025.54.0.693095684062.issue4449@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
./python Doc/includes/mp_benchmarks.py
######## testing Array("i", ..., lock=False)
Traceback (most recent call last):
File "Doc/includes/mp_benchmarks.py", line 235, in <module>
test()
File "Doc/includes/mp_benchmarks.py", line 203, in test
test_seqspeed(multiprocessing.Array('i', range(10), lock=False))
File
"/home/heimes/dev/python/release26-maint/Lib/multiprocessing/__init__.py",
line 254, in Array
return Array(typecode_or_type, size_or_initializer, **kwds)
File
"/home/heimes/dev/python/release26-maint/Lib/multiprocessing/sharedctypes.py",
line 87, in Array
assert hasattr(lock, 'acquire')
AssertionError
The assertion error occurs when using Python 2.6 and our backports to
2.4 and 2.5.
----------
assignee: jnoller
components: Library (Lib)
messages: 76525
nosy: christian.heimes, jnoller
priority: high
severity: normal
stage: needs patch
status: open
title: AssertionError in Doc/includes/mp_benchmarks.py
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4449>
_______________________________________
From report at bugs.python.org Fri Nov 28 12:28:21 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 28 Nov 2008 11:28:21 +0000
Subject: [New-bugs-announce] [issue4450] 2to3 run changed
multiprocessing.Queue() to multiprocessing.queue()
In-Reply-To: <1227871701.68.0.713411560639.issue4450@psf.upfronthosting.co.za>
Message-ID: <1227871701.68.0.713411560639.issue4450@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
I've fixed the multiprocessing examples in r67417. 2to3 altered
multiprocessing.Queue() to multiprocessing.queue().
----------
assignee: benjamin.peterson
components: 2to3 (2.x to 3.0 conversion tool)
messages: 76527
nosy: benjamin.peterson, christian.heimes
priority: high
severity: normal
stage: needs patch
status: open
title: 2to3 run changed multiprocessing.Queue() to multiprocessing.queue()
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4450>
_______________________________________
From report at bugs.python.org Fri Nov 28 15:04:51 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 28 Nov 2008 14:04:51 +0000
Subject: [New-bugs-announce] [issue4451] multiprocessing fails with "Invalid
thread state for this thread" on 2.4 and 2.5
In-Reply-To: <1227881091.88.0.574391462042.issue4451@psf.upfronthosting.co.za>
Message-ID: <1227881091.88.0.574391462042.issue4451@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
The multiprocessing backport to 2.4/2.5 fails with a fatal error when
the test suite is run with a debug build of Python.
PYTHONPATH="Lib/" /home/heimes/dev/python/release25-maint/python -tt -c
"from multiprocessing.tests import main; main()"
Fatal Python error: Invalid thread state for this thread
Traceback (most recent call last):
File "<string>", line 1, in <module>
File
"/home/heimes/dev/py/python-multiprocessing/Lib/multiprocessing/tests.py",
line 1826, in main
test_main(unittest.TextTestRunner(verbosity=2).run)
File
"/home/heimes/dev/py/python-multiprocessing/Lib/multiprocessing/tests.py",
line 1805, in test_main
ManagerMixin.pool = ManagerMixin.manager.Pool(4)
File
"/home/heimes/dev/py/python-multiprocessing/Lib/multiprocessing/managers.py",
line 637, in temp
token, exp = self._create(typeid, *args, **kwds)
File
"/home/heimes/dev/py/python-multiprocessing/Lib/multiprocessing/managers.py",
line 535, in _create
conn = self._Client(self._address, authkey=self._authkey)
File
"/home/heimes/dev/py/python-multiprocessing/Lib/multiprocessing/connection.py",
line 142, in Client
answer_challenge(c, authkey)
File
"/home/heimes/dev/py/python-multiprocessing/Lib/multiprocessing/connection.py",
line 373, in answer_challenge
message = connection.recv_bytes(256) # reject large message
EOFError
----------
components: Interpreter Core
messages: 76528
nosy: christian.heimes, jnoller
priority: high
severity: normal
stage: needs patch
status: open
title: multiprocessing fails with "Invalid thread state for this thread" on 2.4 and 2.5
type: crash
versions: Python 2.4, Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4451>
_______________________________________
From report at bugs.python.org Fri Nov 28 15:23:31 2008
From: report at bugs.python.org (Mark Florisson)
Date: Fri, 28 Nov 2008 14:23:31 +0000
Subject: [New-bugs-announce] [issue4452] Incorrect docstring of os.setpgrp
In-Reply-To: <1227882211.37.0.737329471777.issue4452@psf.upfronthosting.co.za>
Message-ID: <1227882211.37.0.737329471777.issue4452@psf.upfronthosting.co.za>
New submission from Mark Florisson <markflorisson88 at gmail.com>:
The docstring of os.setpgrp says 'Make this process a session leader.',
but that's not what setpgrp does. setpgrp() is the same as setpgid(0,
0), which sets the pgid of the calling process to the pid of the calling
process, thus making it a process group leader, not a session leader (it
will still be in the same session). It might say instead 'Make this
process a process group leader.'.
----------
messages: 76529
nosy: eggy
severity: normal
status: open
title: Incorrect docstring of os.setpgrp
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4452>
_______________________________________
From report at bugs.python.org Fri Nov 28 16:23:18 2008
From: report at bugs.python.org (Suraj Barkale)
Date: Fri, 28 Nov 2008 15:23:18 +0000
Subject: [New-bugs-announce] [issue4453] MSI installer shows error message
if "Compile .py files to bytecode" option is selected
In-Reply-To: <1227885798.23.0.30127507321.issue4453@psf.upfronthosting.co.za>
Message-ID: <1227885798.23.0.30127507321.issue4453@psf.upfronthosting.co.za>
New submission from Suraj Barkale <suraj+python at barkale.com>:
If the option to "Compile .py files to bytecode after installation" is
selected during installation (by clicking on "Advanced" button on
"Customize" dialog), installer shows the attached dialog. There seems to
be no problem after installation is finished. I have tested this on
Vista Ultimate SP1 32 bit.
----------
components: Installation
files: SetupError.JPG
messages: 76537
nosy: suraj
severity: normal
status: open
title: MSI installer shows error message if "Compile .py files to bytecode" option is selected
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12146/SetupError.JPG
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4453>
_______________________________________
From report at bugs.python.org Fri Nov 28 20:59:24 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Nov 2008 19:59:24 +0000
Subject: [New-bugs-announce] [issue4454] Coding cookie crashes IDLE
In-Reply-To: <1227902364.04.0.476219606401.issue4454@psf.upfronthosting.co.za>
Message-ID: <1227902364.04.0.476219606401.issue4454@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
Running the following from an edit window with F5 in IDLE 3.0c3 causes a
complete crash. Both edit window and shell window disappear.
# -*- coding: utf-8 -*-
The is copied from what IDLE said to add when I previously ran file with
non-ascii char and no cookie. Same if add pass statement.
Copying the same directly into the shell window appears to work fine.
----------
components: IDLE
messages: 76551
nosy: tjreedy
severity: normal
status: open
title: Coding cookie crashes IDLE
type: crash
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4454>
_______________________________________
From report at bugs.python.org Fri Nov 28 23:42:56 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 28 Nov 2008 22:42:56 +0000
Subject: [New-bugs-announce] [issue4455] No Windows List in IDLE if several
windows have the same title
In-Reply-To: <1227912176.33.0.213369898929.issue4455@psf.upfronthosting.co.za>
Message-ID: <1227912176.33.0.213369898929.issue4455@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:
Start IDLE, and hit Ctrl-N twice to create two windows named "Untitled":
This displays the message
"""
warning: callback failed in WindowList <class 'TypeError'> : unorderable
types: ListedToplevel() < ListedToplevel()
"""
And the "Windows" menu does not contain the windows list.
This is specific to python 3: Windows objects cannot be ordered any
more. Patch is attached.
----------
files: windowslist.patch
keywords: needs review, patch
messages: 76562
nosy: amaury.forgeotdarc
priority: release blocker
severity: normal
status: open
title: No Windows List in IDLE if several windows have the same title
versions: Python 3.0
Added file: http://bugs.python.org/file12150/windowslist.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4455>
_______________________________________
From report at bugs.python.org Fri Nov 28 23:43:51 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 28 Nov 2008 22:43:51 +0000
Subject: [New-bugs-announce] [issue4456] xmlrpc is broken
In-Reply-To: <1227912231.04.0.126109133889.issue4456@psf.upfronthosting.co.za>
Message-ID: <1227912231.04.0.126109133889.issue4456@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <musiccomposition at gmail.com>:
It looks there are logic problems with regards to encoding in xmlrpc:
if not isinstance(methodname, str):
methodname = methodname.encode(encoding)
Merging r67370 and running test_xmlrpc gives:
test_bug_1164912 (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_cmp_datetime_DateTime (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_datetime_before_1900 (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_dump_bad_dict (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_dump_bare_datetime (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_dump_big_int (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_dump_big_long (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_dump_load (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_dump_none (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_dump_recursive_dict (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_dump_recursive_seq (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_newstyle_class (test.test_xmlrpc.XMLRPCTestCase) ... ok
test_escape (test.test_xmlrpc.HelperTestCase) ... ok
test_datetime_datetime (test.test_xmlrpc.DateTimeTestCase) ... ok
test_decode (test.test_xmlrpc.DateTimeTestCase) ... ok
test_default (test.test_xmlrpc.DateTimeTestCase) ... ok
test_repr (test.test_xmlrpc.DateTimeTestCase) ... ok
test_time (test.test_xmlrpc.DateTimeTestCase) ... ok
test_time_struct (test.test_xmlrpc.DateTimeTestCase) ... ok
test_time_tuple (test.test_xmlrpc.DateTimeTestCase) ... ok
test_decode (test.test_xmlrpc.BinaryTestCase) ... ok
test_default (test.test_xmlrpc.BinaryTestCase) ... ok
test_string (test.test_xmlrpc.BinaryTestCase) ... ok
test_dotted_attribute (test.test_xmlrpc.FaultTestCase) ... ok
test_dump_fault (test.test_xmlrpc.FaultTestCase) ... ok
test_repr (test.test_xmlrpc.FaultTestCase) ... ok
test_custom_user_agent (test.test_xmlrpc.TransportSubclassTestCase) ...
ERROR
test_send_content (test.test_xmlrpc.TransportSubclassTestCase) ... ERROR
test_send_host (test.test_xmlrpc.TransportSubclassTestCase) ... ERROR
test_send_request (test.test_xmlrpc.TransportSubclassTestCase) ... ERROR
test_dotted_attribute (test.test_xmlrpc.SimpleServerTestCase) ... ok
test_introspection1 (test.test_xmlrpc.SimpleServerTestCase) ... ok
test_introspection2 (test.test_xmlrpc.SimpleServerTestCase) ... ok
test_introspection3 (test.test_xmlrpc.SimpleServerTestCase) ... ok
test_introspection4 (test.test_xmlrpc.SimpleServerTestCase) ... ok
test_multicall (test.test_xmlrpc.SimpleServerTestCase) ... ok
test_non_existing_multicall (test.test_xmlrpc.SimpleServerTestCase) ... ok
test_simple1 (test.test_xmlrpc.SimpleServerTestCase) ... ok
test_basic (test.test_xmlrpc.FailingServerTestCase) ... ok
test_fail_no_info (test.test_xmlrpc.FailingServerTestCase) ... ok
test_fail_with_info (test.test_xmlrpc.FailingServerTestCase) ... ok
test_cgi_get (test.test_xmlrpc.CGIHandlerTestCase) ... ok
test_cgi_xmlrpc_response (test.test_xmlrpc.CGIHandlerTestCase) ... ok
======================================================================
ERROR: test_custom_user_agent (test.test_xmlrpc.TransportSubclassTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 657, in
test_custom_user_agent
req = self.issue_request(TestTransport)
File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 645, in
issue_request
proxy.pow(6, 8)
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1095, in __call__
return self.__send(self.__name, args)
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1353, in __request
verbose=self.__verbose
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1136, in request
return self._parse_response(resp, None)
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1246, in
_parse_response
p.feed(response)
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 516, in feed
self._parser.Parse(data, 0)
xml.parsers.expat.ExpatError: mismatched tag: line 12, column 2
======================================================================
ERROR: test_send_content (test.test_xmlrpc.TransportSubclassTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 687, in
test_send_content
req = self.issue_request(TestTransport)
File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 645, in
issue_request
proxy.pow(6, 8)
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1095, in __call__
return self.__send(self.__name, args)
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1353, in __request
verbose=self.__verbose
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1136, in request
return self._parse_response(resp, None)
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1246, in
_parse_response
p.feed(response)
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 516, in feed
self._parser.Parse(data, 0)
xml.parsers.expat.ExpatError: mismatched tag: line 12, column 2
======================================================================
ERROR: test_send_host (test.test_xmlrpc.TransportSubclassTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 667, in
test_send_host
req = self.issue_request(TestTransport)
File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 645, in
issue_request
proxy.pow(6, 8)
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1095, in __call__
return self.__send(self.__name, args)
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1353, in __request
verbose=self.__verbose
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1136, in request
return self._parse_response(resp, None)
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1246, in
_parse_response
p.feed(response)
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 516, in feed
self._parser.Parse(data, 0)
xml.parsers.expat.ExpatError: mismatched tag: line 12, column 2
======================================================================
ERROR: test_send_request (test.test_xmlrpc.TransportSubclassTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 677, in
test_send_request
req = self.issue_request(TestTransport)
File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 645, in
issue_request
proxy.pow(6, 8)
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1095, in __call__
return self.__send(self.__name, args)
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1353, in __request
verbose=self.__verbose
File "/temp/python/py3k/Lib/xmlrpc/client.py", line 1124, in request
http_conn = self.send_request(host, handler, request_body, verbose)
File "/temp/python/py3k/Lib/test/test_xmlrpc.py", line 675, in
send_request
conn.putheader("X-Test", "test_send_request")
AttributeError: 'str' object has no attribute 'putheader'
----------------------------------------------------------------------
----------
components: Library (Lib)
messages: 76563
nosy: benjamin.peterson, jhylton
priority: release blocker
severity: normal
stage: needs patch
status: open
title: xmlrpc is broken
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4456>
_______________________________________
From report at bugs.python.org Sat Nov 29 05:40:54 2008
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 29 Nov 2008 04:40:54 +0000
Subject: [New-bugs-announce] [issue4457] __import__ documentation obsolete
In-Reply-To: <1227933654.59.0.602366149216.issue4457@psf.upfronthosting.co.za>
Message-ID: <1227933654.59.0.602366149216.issue4457@psf.upfronthosting.co.za>
New submission from Steven D'Aprano <steve at pearwood.info>:
The documentation for __import__ says that it primarily exists "so that
you can replace it with another function that has a compatible
interface, in order to change the semantics of the import statement".
http://docs.python.org/library/functions.html
That is no longer the case. The recommended way to do that is with the
new import hooks, and the docs should reflect that.
A common use for __import__ is for when you don't know the module name
until runtime. That too should be mentioned.
----------
assignee: georg.brandl
components: Documentation
messages: 76582
nosy: georg.brandl, stevenjd
severity: normal
status: open
title: __import__ documentation obsolete
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4457>
_______________________________________
From report at bugs.python.org Sat Nov 29 06:04:00 2008
From: report at bugs.python.org (Yevgen Muntyan)
Date: Sat, 29 Nov 2008 05:04:00 +0000
Subject: [New-bugs-announce] [issue4458] getopt.gnu_getopt() loses dash
argument
In-Reply-To: <1227935040.48.0.357266334466.issue4458@psf.upfronthosting.co.za>
Message-ID: <1227935040.48.0.357266334466.issue4458@psf.upfronthosting.co.za>
New submission from Yevgen Muntyan <muntyan at tamu.edu>:
If you feed a dash as an argument to getopt.gnu_getopt() then it gets
lost, because the code only checks if the argument starts with a dash,
not if it's more than a dash (unlike getopt.getopt() which is correct).
Example:
>>> import getopt
>>> getopt.gnu_getopt('-', '')
([], [])
>>> getopt.getopt('-', '')
([], '-')
----------
components: Library (Lib)
messages: 76583
nosy: muntyan
severity: normal
status: open
title: getopt.gnu_getopt() loses dash argument
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4458>
_______________________________________
From report at bugs.python.org Sat Nov 29 15:42:31 2008
From: report at bugs.python.org (John5342)
Date: Sat, 29 Nov 2008 14:42:31 +0000
Subject: [New-bugs-announce] [issue4459] bdist_rpm assumes python
In-Reply-To: <1227969751.28.0.990351219395.issue4459@psf.upfronthosting.co.za>
Message-ID: <1227969751.28.0.990351219395.issue4459@psf.upfronthosting.co.za>
New submission from John5342 <John5342 at googlemail.com>:
When using bdist_rpm the %build section of the generated spec file
contains the following:
env CFLAGS="$RPM_OPT_FLAGS" python setup.py build
This works fine until the python is installed using altinstall. In this
situation the spec file will use the default python rather than the one
currently used.
I am currently using python3.0 with the default python being 2.5. As a
result the spec file is created which then calles python (2.5) and my
setup.py contains 3.0 code so the spec file fails.
When the above line is generated it should use the current interpreters
path and name rather than just "python"
----------
components: Distutils
messages: 76596
nosy: John5342
severity: normal
status: open
title: bdist_rpm assumes python
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4459>
_______________________________________
From report at bugs.python.org Sat Nov 29 17:35:42 2008
From: report at bugs.python.org (Brian Szuter)
Date: Sat, 29 Nov 2008 16:35:42 +0000
Subject: [New-bugs-announce] [issue4460] The parameter of PyInt_AsSsize_t()
is not checked to see if it is NULL
In-Reply-To: <1227976542.96.0.0797297401502.issue4460@psf.upfronthosting.co.za>
Message-ID: <1227976542.96.0.0797297401502.issue4460@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
Python-2.5.2/Modules/_sre.c(match_getindex)
Line 2766
The parameter of PyInt_AsSsize_t() is not checked to see if it is NULL.
----------
components: None
messages: 76600
nosy: CWRU_Researcher1
severity: normal
status: open
title: The parameter of PyInt_AsSsize_t() is not checked to see if it is NULL
type: resource usage
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4460>
_______________________________________
From report at bugs.python.org Sat Nov 29 17:54:38 2008
From: report at bugs.python.org (Brian Szuter)
Date: Sat, 29 Nov 2008 16:54:38 +0000
Subject: [New-bugs-announce] [issue4461] parameters of PyLong_FromString()
are not checked for NULL
In-Reply-To: <1227977678.79.0.85235656818.issue4461@psf.upfronthosting.co.za>
Message-ID: <1227977678.79.0.85235656818.issue4461@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
Python-2.5.2/Python/ast.c(parsenumber)
Line 3061
The parameters of PyLong_FromString() are not checked for NULL before
the method is called.
----------
components: None
messages: 76602
nosy: CWRU_Researcher1
severity: normal
status: open
title: parameters of PyLong_FromString() are not checked for NULL
type: resource usage
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4461>
_______________________________________
From report at bugs.python.org Sat Nov 29 17:59:43 2008
From: report at bugs.python.org (Brian Szuter)
Date: Sat, 29 Nov 2008 16:59:43 +0000
Subject: [New-bugs-announce] [issue4462] result of PyList_GetItem() not
validated
In-Reply-To: <1227977983.78.0.00196482293309.issue4462@psf.upfronthosting.co.za>
Message-ID: <1227977983.78.0.00196482293309.issue4462@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
Python-2.5.2/Python/import.c(find_module)
Lines 1171
PyString_Check() is not called on the result of PyList_GetItem(), nor is
the result checked to see if it is NULL.
----------
components: None
messages: 76603
nosy: CWRU_Researcher1
severity: normal
status: open
title: result of PyList_GetItem() not validated
type: resource usage
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4462>
_______________________________________
From report at bugs.python.org Sat Nov 29 18:02:14 2008
From: report at bugs.python.org (Brian Szuter)
Date: Sat, 29 Nov 2008 17:02:14 +0000
Subject: [New-bugs-announce] [issue4463] Parameters and result of
PyList_GetItem() are not validated
In-Reply-To: <1227978134.48.0.524968542357.issue4463@psf.upfronthosting.co.za>
Message-ID: <1227978134.48.0.524968542357.issue4463@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
Python-2.5.2/Python/import.c(get_path_importer)
Lines 1079
PyString_Check() is not called on the result of PyList_GetItem() and the
parameters of PyList_GetItem() are not validated before the method is
called.
----------
components: None
messages: 76604
nosy: CWRU_Researcher1
severity: normal
status: open
title: Parameters and result of PyList_GetItem() are not validated
type: performance
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4463>
_______________________________________
From report at bugs.python.org Sat Nov 29 18:06:35 2008
From: report at bugs.python.org (Brian Szuter)
Date: Sat, 29 Nov 2008 17:06:35 +0000
Subject: [New-bugs-announce] [issue4464] PyList_GetItem() result and
parameters not fully validated
In-Reply-To: <1227978395.86.0.799094154401.issue4464@psf.upfronthosting.co.za>
Message-ID: <1227978395.86.0.799094154401.issue4464@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
Python-2.5.2/Python/codecs.c(_PyCodec_Lookup)
Lines 106, 144
PyString_Check() is not called on the result of PyList_GetItem() and the
first parameter of PyList_GetItem() does not have PyList_Check() called
on it.
(See Python-2.5.2/Python/traceback.c(tb_displayline) for a correct
instance of the pattern)
----------
components: None
messages: 76605
nosy: CWRU_Researcher1
severity: normal
status: open
title: PyList_GetItem() result and parameters not fully validated
type: performance
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4464>
_______________________________________
From report at bugs.python.org Sat Nov 29 18:12:26 2008
From: report at bugs.python.org (Brian Szuter)
Date: Sat, 29 Nov 2008 17:12:26 +0000
Subject: [New-bugs-announce] [issue4465] The result of set_copy() is not
checked for NULL
In-Reply-To: <1227978746.73.0.948517035372.issue4465@psf.upfronthosting.co.za>
Message-ID: <1227978746.73.0.948517035372.issue4465@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
Python-2.5.2/Objects/setobject.c
Line 1204
The result of set_copy() is not checked for NULL.
[See Objects/setobject.c(set_difference) for example of correct usage]
----------
components: None
messages: 76606
nosy: CWRU_Researcher1
severity: normal
status: open
title: The result of set_copy() is not checked for NULL
type: performance
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4465>
_______________________________________
From report at bugs.python.org Sat Nov 29 18:40:45 2008
From: report at bugs.python.org (Brian Szuter)
Date: Sat, 29 Nov 2008 17:40:45 +0000
Subject: [New-bugs-announce] [issue4466] The return value of PyFile_FromFile
is not checked for NULL
In-Reply-To: <1227980445.15.0.00624503255277.issue4466@psf.upfronthosting.co.za>
Message-ID: <1227980445.15.0.00624503255277.issue4466@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
Python-2.5.2/Modules/posixmodule.c(posix_tmpfile)
Line 6841
The return value of PyFile_FromFile is not checked for NULL
See the following where it is checked:
tokenizer.c(fp_setreadl) 429
fileobject.c(PyFile_FromString) 300
posixmodule.c(posix_popen) 5323
----------
messages: 76611
nosy: CWRU_Researcher1
severity: normal
status: open
title: The return value of PyFile_FromFile is not checked for NULL
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4466>
_______________________________________
From report at bugs.python.org Sat Nov 29 18:59:47 2008
From: report at bugs.python.org (Brian Szuter)
Date: Sat, 29 Nov 2008 17:59:47 +0000
Subject: [New-bugs-announce] [issue4467] return value of
PyUnicode_AsEncodedString() is not checked for NULL
In-Reply-To: <1227981587.71.0.239031040576.issue4467@psf.upfronthosting.co.za>
Message-ID: <1227981587.71.0.239031040576.issue4467@psf.upfronthosting.co.za>
New submission from Brian Szuter <Brian.Szuter at gmail.com>:
Python-2.5.2/Objects/unicodeobject.c(unicode_str)
Line 6816
The return value of PyUnicode_AsEncodedString() is not checked for NULL.
According to
http://www.python.org/doc/2.5.2/api/builtinCodecs.html#l2h-519 this
indicates an exception occurred.
See the following for instances of where this value is checked:
Parser/tokenizer.c(tok_stdin_decode) 726
Parser/tokenizer.c(dec_utf8) 1555
Objects/object.c(PyObject_GenericSetAttr) 1386
Objects/object.c(PyObject_GenericGetAttr) 1260
Objects/object.c(PyObject_SetAttr) 1161
Objects/object.c(PyObject_Str) 434-437
Objects/stringobject.c(PyString_AsEncodedString) 501
Objects/stringobject.c(PyString_AsDecodedString) 421
Objects/unicodeobject.c(_PyUnicodeUCS2_AsDefaultEncodedString) 735
----------
components: None
messages: 76614
nosy: CWRU_Researcher1
severity: normal
status: open
title: return value of PyUnicode_AsEncodedString() is not checked for NULL
type: performance
versions: Python 2.5.3
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4467>
_______________________________________
From report at bugs.python.org Sun Nov 30 09:57:35 2008
From: report at bugs.python.org (Kay Schluehr)
Date: Sun, 30 Nov 2008 08:57:35 +0000
Subject: [New-bugs-announce] [issue4468] Restore chapter enumeration in
Python docs
In-Reply-To: <1228035455.3.0.341155403545.issue4468@psf.upfronthosting.co.za>
Message-ID: <1228035455.3.0.341155403545.issue4468@psf.upfronthosting.co.za>
New submission from Kay Schluehr <kay at fiber-space.de>:
Request for restoring chapter enumeration in the Python docs for Python
2.6 and newer releases.
In the new style Sphinx documentation for Python the enumeration of
sections and subsections has been dropped. This is highly unusual for a
technical documentation and in particular for a body of documents that
represent a de-facto standard. An easy access to content is required
even in communication being not web based where URLs can be copied and
sent. Even right now the chm documents provided in the Windows
distribution of Python 2.6 are of reduced value. Given that there are
chapters with pretty generic titles like "How it works" the lack of
enumeration causes disorientation.
----------
assignee: georg.brandl
components: Documentation
messages: 76634
nosy: georg.brandl, schluehk
severity: normal
status: open
title: Restore chapter enumeration in Python docs
type: feature request
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4468>
_______________________________________
From report at bugs.python.org Sun Nov 30 14:38:53 2008
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 30 Nov 2008 13:38:53 +0000
Subject: [New-bugs-announce] [issue4469] CVE-2008-5031 multiple integer
overflows
In-Reply-To: <1228052333.35.0.166385474825.issue4469@psf.upfronthosting.co.za>
Message-ID: <1228052333.35.0.166385474825.issue4469@psf.upfronthosting.co.za>
New submission from Matthias Klose <doko at debian.org>:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507317
needs backport of rev 61350 from the trunk.
fixed in newer versions.
----------
components: Interpreter Core
messages: 76638
nosy: doko
priority: release blocker
severity: normal
status: open
title: CVE-2008-5031 multiple integer overflows
type: security
versions: Python 2.4
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4469>
_______________________________________
From report at bugs.python.org Sun Nov 30 17:23:34 2008
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Sun, 30 Nov 2008 16:23:34 +0000
Subject: [New-bugs-announce] [issue4470] smtplib SMTP_SSL not working.
In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
Message-ID: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za>
New submission from Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:
The enclosed patch does three things:
1. enables SMTP_SSL working: the _get_socket method was setting
self.sock instead of returning the socket to the caller, which
did reset self.sock to None
2. replace home-grown SSLFakeFile() with calls to ssl.socket's makefile()
calls both in the starttls and in the SMTP_SSL cases
3. shutdown sockets before closing them, to avoid server-side piling and
connection refused on connection-limited servers
The last change is just a cosmetical refactoring, but it really helps
the SMTP_SSL case: default_port should really be a class attribute,
instead of being set at __init__ time.
----------
components: Library (Lib)
files: smtplib.py.patch
keywords: patch
messages: 76640
nosy: lcatucci
severity: normal
status: open
title: smtplib SMTP_SSL not working.
versions: Python 2.6
Added file: http://bugs.python.org/file12168/smtplib.py.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4470>
_______________________________________
From report at bugs.python.org Sun Nov 30 17:33:16 2008
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Sun, 30 Nov 2008 16:33:16 +0000
Subject: [New-bugs-announce] [issue4471] IMAP4 missing support for starttls
In-Reply-To: <1228062796.45.0.215183772699.issue4471@psf.upfronthosting.co.za>
Message-ID: <1228062796.45.0.215183772699.issue4471@psf.upfronthosting.co.za>
New submission from Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:
In the enclosed patch, there are three changes:
1. Support starttls on IMAP4 connections
2. Rework of the IMAP_SSL, to replace home-grown file-like
methods with proper ones from ssl module's makefile();
3. Properly shutdown sockets at close() time to avoid server-side pile-up
----------
components: Library (Lib)
files: imaplib.py.patch
keywords: patch
messages: 76641
nosy: lcatucci
severity: normal
status: open
title: IMAP4 missing support for starttls
versions: Python 2.6
Added file: http://bugs.python.org/file12169/imaplib.py.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4471>
_______________________________________
From report at bugs.python.org Sun Nov 30 17:37:55 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 30 Nov 2008 16:37:55 +0000
Subject: [New-bugs-announce] [issue4472] Is shared lib building broken on
trunk?
In-Reply-To: <18738.49496.996446.483821@montanaro-dyndns-org.local>
Message-ID: <18738.49496.996446.483821@montanaro-dyndns-org.local>
New submission from Skip Montanaro <skip at pobox.com>:
I have tried several different combinations of configure args on my Mac in
the past couple days in a so far fruitless attempt to generate a
libpython.2.7.dylib file. All it will ever generate is a .a file. I've
come to the conclusion that building a shared Python library is broken, at
least on Macs. I only even noticed this because I wanted to bundle up a
trivial little Python script as a Mac app build. py2app requires a dylib
file to generate the app bundle (to include?).
I build in separate build directories so I can have normal, debug and
framework builds. Here's the configure command from my framework build:
../configure --prefix=/Users/skip/local --enable-shared \
'--enable-framework=/Users/skip/Applications' \
'CPPFLAGS=-I/Users/skip/local/include -I/opt/local/include' \
'LDFLAGS=-L/Users/skip/local/lib -L/opt/local/lib'
I've tried taking out the --prefix and/or --enable-shared flags thinking
maybe the --enable-framework flag was sufficient. I've tried making the
sharedinstall target. I never see anything like -fPIC or -fpic in the gcc
command line args. In fact, I don't see "dylib" or "pic" mentioned in the
Makefile at all.
I gave up building in a subdirectory then whittled the configure command
down to this:
./configure --prefix=/Users/skip/local --enable-shared \
'--enable-framework=/Users/skip/Applications'
make clean. make. Still no libpython.2.7.dylib file.
Skip
----------
messages: 76642
nosy: skip.montanaro
severity: normal
status: open
title: Is shared lib building broken on trunk?
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4472>
_______________________________________
From report at bugs.python.org Sun Nov 30 17:39:03 2008
From: report at bugs.python.org (Lorenzo M. Catucci)
Date: Sun, 30 Nov 2008 16:39:03 +0000
Subject: [New-bugs-announce] [issue4473] POP3 missing support for starttls
In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
Message-ID: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za>
New submission from Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>:
In the enclosed patch, there are four changes
1. add support for the optional CAPA pop command, since it is needed
for starttls support discovery
2. add support for the STLS pop command
3. replace home-grown file-like methods and replace them with ssl
socket's makefile() in POP3_SSL
4. Properly shutdown sockets at close() time to avoid server-side pile-up
----------
files: poplib.py.patch
keywords: patch
messages: 76643
nosy: lcatucci
severity: normal
status: open
title: POP3 missing support for starttls
Added file: http://bugs.python.org/file12170/poplib.py.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4473>
_______________________________________
From report at bugs.python.org Sun Nov 30 19:54:08 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 30 Nov 2008 18:54:08 +0000
Subject: [New-bugs-announce] [issue4474] PyUnicode_FromWideChar incorrect
for characters outside the BMP (unix only)
In-Reply-To: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
Message-ID: <1228071248.49.0.10094276273.issue4474@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
On systems (Linux, OS X) where sizeof(wchar_t) is 4 and wchar_t arrays are
usually encoded as UTF-32, it looks as though PyUnicode_FromWideChar
simply truncates the 32-bit characters to 16-bits, thus giving incorrect
results for characters outside the BMP. I expected it to convert the UTF-
32 encoding to UTF-16.
Note that PyUnicode_FromWideChar is used to process command-line
arguments, so strange things can happen when passing filenames with non-
BMP characters to a Python script.
Here's an OS X 10.5 Terminal session (current directory is the root of the
py3k tree).
dickinsm$ cat test??.py
from sys import argv
print("My arguments are: ",argv)
dickinsm$ ./python.exe test??.py
My arguments are: ['test?.py']
dickinsm$ ./python.exe Lib/tabnanny.py test??.py
'test?.py': I/O Error: [Errno 2] No such file or directory: 'test?.py'
(In case the character after 'test' and before '.py' isn't showing up
correctly, it's chr(65901), 'GREEK ACROPHONIC TROEZENIAN FIVE HUNDRED'.)
----------
components: Interpreter Core
messages: 76651
nosy: marketdickinson
severity: normal
status: open
title: PyUnicode_FromWideChar incorrect for characters outside the BMP (unix only)
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4474>
_______________________________________
From report at bugs.python.org Sun Nov 30 20:55:32 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 30 Nov 2008 19:55:32 +0000
Subject: [New-bugs-announce] [issue4475] More verbose error message for
Py_FindMethod
In-Reply-To: <1228074932.76.0.882771479125.issue4475@psf.upfronthosting.co.za>
Message-ID: <1228074932.76.0.882771479125.issue4475@psf.upfronthosting.co.za>
New submission from Guilherme Polo <ggpolo at gmail.com>:
As was told in
http://mail.python.org/pipermail/python-dev/2008-November/083782.html
some objects may print a not so nice message when an attribute is not
found.
I considered this was due to Py_FindMethod being so easy to use that is
probably used in several extensions but it doesn't set a good error message.
----------
components: Interpreter Core
files: FindMethod_verbose_err.diff
keywords: patch
messages: 76659
nosy: gpolo
severity: normal
status: open
title: More verbose error message for Py_FindMethod
versions: Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12175/FindMethod_verbose_err.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4475>
_______________________________________