[issue13541] HTTPResponse (urllib) has no attribute read1 needed for TextIOWrapper

[Peter]

New submission from Peter :

Use case: I want to open an HTTP URL, and treat the handle as though it were 
opened in text mode (i.e. unicode strings not bytes).

$ python3
Python 3.2 (r32:88445, Feb 28 2011, 17:04:33) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import io
>>> import urllib.request
>>> f_bytes = urllib.request.urlopen("http://www.python.org";)
>>> for line in io.TextIOWrapper(f_bytes, "iso-8859-1"): print(line)
... 
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'HTTPResponse' object has no attribute 'read1'

See also Slide 122 of 
http://www.slideshare.net/dabeaz/mastering-python-3-io-version-2 which reports 
the same exception.

See also issue 5628 on a related issue, where Benjamin Peterson's issue 5628 
message 84970 suggests double wrapping with BufferIOBase [sic] to solve this, 
but neither of the following works for me:

>>> f_bytes = urllib.request.urlopen("http://www.python.org";)
>>> for line in io.TextIOWrapper(io.BufferedIOBase(f_bytes), "iso-8859-1"): 
>>> print(line)
... 
Traceback (most recent call last):
  File "", line 1, in 
io.UnsupportedOperation: not readable


>>> f_bytes = urllib.request.urlopen("http://www.python.org";)
>>> for line in io.TextIOWrapper(io.BufferedReader(f_bytes), "iso-8859-1"): 
>>> print(line)
... 
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'HTTPResponse' object has no attribute 'readinto'


Nor incidentally does this:


>>> f_bytes = urllib.request.urlopen("http://www.python.org";)
>>> for line in io.BufferedReader(f_bytes): print(line)
... 
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'HTTPResponse' object has no attribute 'readinto'


See also issue 4996.

It is entirely possible I have simply failed to understand the proper way to do 
this, so at very least an example on the urllib documentation would be a 
welcome improvement. However it is my impression that the file-like object from 
urllib is not file-like enough.

--
messages: 148928
nosy: maubp
priority: normal
severity: normal
status: open
title: HTTPResponse (urllib) has no attribute read1 needed for TextIOWrapper
versions: Python 3.2

___
Python tracker 
<http://bugs.python.org/issue13541>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10353] 2to3 and places argument in unitests assertAlmostEqual

[Peter]

New submission from Peter :

Consider the following example unit test using assertAlmostEqual which uses the 
places argument as a positional argument, call this places.py:

import unittest
class Tests(unittest.TestCase):
def test_equal_to_five_decimal_places(self):
"""Check assertAlmostEqual using decimal places"""
self.assertAlmostEqual(0.123456789, 0.123456, 5)
if __name__ == "__main__":
runner = unittest.TextTestRunner(verbosity = 2)
unittest.main(testRunner=runner)



This works fine with Python 2.6.6 (Linux),

$ python2.6 places.py
Check assertAlmostEqual using decimal places ... ok

--
Ran 1 test in 0.000s

OK




Trying 2to3 on it reports no changes needed:

$ 2to3 places.py
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: No changes to places.py
RefactoringTool: Files that need to be modified:
RefactoringTool: places.py


Trying the test as is under Python 3.1.2 (Linux) fails:

$ python3.1 places.py
test_equal_to_five_decimal_places (__main__.Tests)
Check assertAlmostEqual using decimal places ... ERROR

==
ERROR: test_equal_to_five_decimal_places (__main__.Tests)
Check assertAlmostEqual using decimal places
--
Traceback (most recent call last):
  File "places.py", line 5, in test_equal_to_five_decimal_places
self.assertAlmostEqual(0.123456789, 0.123456, 5)
TypeError: assertAlmostEqual() takes exactly 3 positional arguments (4 given)

--
Ran 1 test in 0.001s

FAILED (errors=1)


The test can be fixed to run on Python 3.1 (any Python 2.6) by supplying the 
places argument by name:


import unittest
class Tests(unittest.TestCase):
def test_equal_to_five_decimal_places(self):
"""Check assertAlmostEqual using decimal places"""
self.assertAlmostEqual(0.123456789, 0.123456, places=5)
if __name__ == "__main__":
runner = unittest.TextTestRunner(verbosity = 2)
unittest.main(testRunner=runner)


Note http://docs.python.org/library/unittest.html does not explicitly discuss 
passing places by name vs position. On the other hand, 
http://docs.python.org/py3k/library/unittest.html explicitly shows the by name 
form only.

I think the 2to3 script needs to be extended to use the places argument by name.

--
components: 2to3 (2.x to 3.0 conversion tool)
messages: 120728
nosy: maubp
priority: normal
severity: normal
status: open
title: 2to3 and places argument in unitests assertAlmostEqual
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

___
Python tracker 
<http://bugs.python.org/issue10353>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10777] xml.etree.register_namespace dictionary changed size during iteration

[Peter]

New submission from Peter :

The following was found testing the Biopython unit tests (latest code from git) 
against Python 3.2 beta 2 (compiled from source on 64 bit Linux Ubuntu). 
Reduced test case:

$ python3.2
Python 3.2b2 (r32b2:87398, Dec 26 2010, 19:01:30) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree import ElementTree
>>> ElementTree.register_namespace("xs", "http://www.w3.org/2001/XMLSchema";)
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/peterjc/lib/python3.2/xml/etree/ElementTree.py", line 1071, in 
register_namespace
for k, v in _namespace_map.items():
RuntimeError: dictionary changed size during iteration


Suggested fix, replace this:

def register_namespace(prefix, uri):
if re.match("ns\d+$", prefix):
raise ValueError("Prefix format reserved for internal use")
for k, v in _namespace_map.items():
if k == uri or v == prefix:
del _namespace_map[k]
_namespace_map[uri] = prefix


with something like this:

def register_namespace(prefix, uri):
if re.match("ns\d+$", prefix):
raise ValueError("Prefix format reserved for internal use")
for k, v in list(_namespace_map.items()):
if k == uri or v == prefix:
del _namespace_map[k]
_namespace_map[uri] = prefix


Note that cElementTree seems to be OK.

Note that Python 3.1 was not affected as it didn't even have register_namespace,

$ python3
Python 3.1.2 (r312:79147, Sep 27 2010, 09:57:50) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree import ElementTree
>>> ElementTree.register_namespace("xs", "http://www.w3.org/2001/XMLSchema";)
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'register_namespace'

--
components: XML
messages: 124688
nosy: maubp
priority: normal
severity: normal
status: open
title: xml.etree.register_namespace dictionary changed size during iteration
type: crash
versions: Python 3.2

___
Python tracker 
<http://bugs.python.org/issue10777>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9257] cElementTree iterparse requires events as bytes; ElementTree uses strings

[Peter]

Peter  added the comment:

This wasn't fixed in Python 3.1.3 either.

Is the trunk commit Amaury identified from py3k branch (r78942) suitable to 
back port to Python 3.1.x?

--

___
Python tracker 
<http://bugs.python.org/issue9257>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10148] st_mtime differs after shutil.copy2

[Peter]

Peter  added the comment:

I'm also seeing this on 32bit Windows XP using Python 3.1.2, and Python 3.2rc1 
on a local NTFS filesystem.

e.g. from os.stat(filename).st_mtime after using shutil.copy2(...)

1293634856.1402586 source
1293634856.1402581 copied

I've been using shutil.copy2 then expecting st_mtime will be equal (or at least 
that the copy file will be newer than the original). As you can see in this 
case, the copy is sometimes a fraction older.

The same issue occurs using shutil.copy then shutils.copystat (probably not a 
surprise).

--
nosy: +maubp

___
Python tracker 
<http://bugs.python.org/issue10148>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2859] sphinx and virtualenv

[Peter]

New submission from Peter <[EMAIL PROTECTED]>:

I tried to install sphinx with virtualenv.The error message is showing a
missing file:

...
INFORMATION
  the speedup extension could not be compiled, Jinja will
  fall back to the native python classes.
===
error: Setup script exited with error: can't copy
'Jinja.egg-info/native_libs.txt': doesn't exist or not a regular file
[@|] (todo_sphinx)[EMAIL PROTECTED] ~/_kurse/zope3/todo_sphinx $
./bin/sphinx-quickstart --help
Traceback (most recent call last):
  File "./bin/sphinx-quickstart", line 5, in ?
from pkg_resources import load_entry_point
  File
"/home/peter/_kurse/zope3/todo_sphinx/lib/python2.4/site-packages/setuptools-0.6c7-py2.4.egg/pkg_resources.py",
line 2561, in ?
working_set.require(__requires__)
  File
"/home/peter/_kurse/zope3/todo_sphinx/lib/python2.4/site-packages/setuptools-0.6c7-py2.4.egg/pkg_resources.py",
line 626, in require
needed = self.resolve(parse_requirements(requirements))
  File
"/home/peter/_kurse/zope3/todo_sphinx/lib/python2.4/site-packages/setuptools-0.6c7-py2.4.egg/pkg_resources.py",
line 524, in resolve
raise DistributionNotFound(req)  # XXX put more info here
pkg_resources.DistributionNotFound: Jinja>=1.1

--
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 66846
nosy: georg.brandl, peterK
severity: normal
status: open
title: sphinx and virtualenv
versions: Python 2.4

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2859>
__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3207] file.write() after file.readline() in mode "r+"

[Peter]

New submission from Peter <[EMAIL PROTECTED]>:

Following code:
   fp = open("delete.me", "r+t")
   fp.readline()
   fp.write("New line \n")
   fp.close()

Won't do anything. I mean nor writing to file, nor raising exception. 
Nothing.
I can't find any note about this crap. So, it is the best place for it.

P.S. It's my first bug-report and I think I was wrong in filling bug-
form. Sorry.

--
assignee: georg.brandl
components: Documentation
messages: 68773
nosy: georg.brandl, peterdemin
severity: normal
status: open
title: file.write() after file.readline() in mode "r+"
type: performance
versions: Python 2.5

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3207>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3207] file.write() after file.readline() in mode "r+"

[Peter]

Peter <[EMAIL PROTECTED]> added the comment:

Sorry. I use Windows XP SP2 with all updates on 26.06.2008
Python 2.5.2

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3207>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3207] file.write() after file.readline() in mode "r+"

[Peter]

Changes by Peter <[EMAIL PROTECTED]>:


___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3207>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3207] file.write() after file.readline() in mode "r+"

[Peter]

Peter <[EMAIL PROTECTED]> added the comment:

Amaury Forgeot d'Arc, your example really raise IOError 0
Thing is that you had 1 string in the file
Here is it:
>>> open("delete.me", "w").write("first\nsecond\nthird")
>>> fp = open("delete.me", "r+t")
>>> fp.readline()
'first\n'
>>> fp.write("Newbie")
>>> fp.close()
>>> open("delete.me", "r").read()
'first\nsecond\nthird'

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3207>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8239] Windows 2.6.5 Installer Advanced Option Generates Error Message During Compile Step

[Peter]

New submission from Peter :

If the installer is run in Windows XP/SP3 without selecting the Advanced 
compiling option, it works fine.  If the installer is run in Windows XP/SP3 and 
the Advanced compiling option is selected, the following error message is 
generated during the compile step:

"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."

The relevant part of the log when the installer fails using the Advanced 
compiling option is as follows:



MSI (s) (4C:B4) [14:41:27:205]: Doing action: CompilePyc
Action 14:41:27: CompilePyc. 
Action start 14:41:27: CompilePyc.
MSI (s) (4C:B4) [14:45:45:528]: Note: 1: 1722 2: CompilePyc 3: C:\bin
\Python26\python.exe 4: -Wi "C:\bin\Python26\Lib\compileall.py" -f -x 
bad_coding|badsyntax|site-packages|py3_ "C:\bin\Python26\Lib" 
MSI (s) (4C:B4) [14:45:45:528]: Note: 1: 2262 2: Error 3: -2147287038 
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: 
C:\bin\Python26\python.exe, command: -Wi "C:\bin\Python26\Lib\compileall.py" -f 
-x bad_coding|badsyntax|site-packages|py3_ "C:\bin\Python26\Lib" 
MSI (s) (4C:B4) [14:47:41:133]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (s) (4C:B4) [14:47:41:133]: Product: Python 2.6.5 -- 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: C:\bin\Python26 
\python.exe, command: -Wi "C:\bin\Python26\Lib\compileall.py" -f -x 
bad_coding|badsyntax|site-packages|py3_ "C:\bin\Python26\Lib" 

Action ended 14:47:41: CompilePyc. Return value 3.
Action ended 14:47:41: INSTALL. Return value 3.



I believe the cause of this installation failure message is due to the 
syntax of the following command:

C:\bin\Python26\python.exe -Wi "C:\bin\Python26\Lib\compileall.py" -f -x 
bad_coding|badsyntax|site-packages|py3_ "C:\bin\Python26\Lib"

If this command is run in the Windows XP shell, it yields an error.  If the -x 
option's args are wrapped in double quotes, it runs ok (except for a syntax 
error when compiling one of the python source files - I don't remember which 
one):

C:\bin\Python26\python.exe -Wi "C:\bin\Python26\Lib\compileall.py" -f -x 
"bad_coding|badsyntax|site-packages|py3_" "C:\bin\Python26\Lib"

So it appears that the Windows XP shell is interpreting the "|" 
characters within the -x option's args as pipe characters and tries to 
pipe the "multiple commands" together.

The simple work around is to not use the Advanced compiling option with this 
release.  If wanted, the compilation step can be performed manually after the 
installation completes.

--
components: Installation, Windows
messages: 101746
nosy: ps1956
severity: normal
status: open
title: Windows 2.6.5 Installer Advanced Option Generates Error Message During 
Compile Step
type: behavior
versions: Python 2.6

___
Python tracker 
<http://bugs.python.org/issue8239>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38633] shutil.copystat fails with PermissionError in WSL

[Peter]

New submission from Peter :

Using shutil.copystat (and therefore also shutil.copytree) in WSL on any 
directories from a mounted Windows drive (i.e. /mnt/c/...) raises an 
shutil.Error "[Errno 13] Permission denied". 

It seems to fail when copying the extended filesystem attribute 
"system.wsl_case_sensitive" using os.setxattr() here: 
https://github.com/python/cpython/blob/da6ce58dd5ac109485af45878fca6bfd265b43e9/Lib/shutil.py#L322

Note that this only happens when both src and dst are on the mounted drive. If 
only one is on the drive and the other is e.g. in the home directory 
/home/username/, it will not raise an error. 

Quick way to test: 

cd /mnt/c/ && mkdir test1 && mkdir test2 && python -c "import shutil; 
shutil.copystat('test1', 'test2')"

--
components: Library (Lib), Windows
messages: 355655
nosy: paul.moore, pspeter, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: shutil.copystat fails with PermissionError in WSL
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 
<https://bugs.python.org/issue38633>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23786] test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error

[Peter]

Peter  added the comment:

We've migrated our python process off Solaris.

--
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue23786>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42900] Ternary operator precedence relative to bitwise or

[Peter]

New submission from Peter :

Hello,

I expect the following code to run fine, but the assertion fails. dbg1 is 1, 
while dbg2 is 3.  I thought they would both be 3.
Note that the only difference between the expressions for dbg1 and dbg2 are the 
parentheses.
Please accept my apologies if this is expected behavior, but it came as a big 
surprise to me.


import json
if __name__ == "__main__":
msg = '''
{
"Sync Setup Flags": {
"Setup Sync": "Enable",
"Generate Primary Sync": "Enable",
"Backup Primary Sync": "Disable",
"Follow Only": "Disable",
"Use Local Clock": "Disable",
"Set Active": "Disable"
}
}
'''
obj = json.loads(msg)
dbg1 = \
1 if obj["Sync Setup Flags"]["Setup Sync"] == "Enable" else 0 | \
2 if obj["Sync Setup Flags"]["Generate Primary Sync"] == "Enable" else 
0 | \
4 if obj["Sync Setup Flags"]["Backup Primary Sync"] == "Enable" else 0 
| \
8 if obj["Sync Setup Flags"]["Follow Only"] == "Enable" else 0 | \
16 if obj["Sync Setup Flags"]["Use Local Clock"] == "Enable" else 0 | \
128 if obj["Sync Setup Flags"]["Set Active"] == "Enable" else 0
dbg2 = \
(1 if obj["Sync Setup Flags"]["Setup Sync"] == "Enable" else 0) | \
(2 if obj["Sync Setup Flags"]["Generate Primary Sync"] == "Enable" else 
0) | \
(4 if obj["Sync Setup Flags"]["Backup Primary Sync"] == "Enable" else 
0) | \
(8 if obj["Sync Setup Flags"]["Follow Only"] == "Enable" else 0) | \
(16 if obj["Sync Setup Flags"]["Use Local Clock"] == "Enable" else 0) | 
\
(128 if obj["Sync Setup Flags"]["Set Active"] == "Enable" else 0)

assert(dbg1 == dbg2)

--
messages: 384874
nosy: amazingmo
priority: normal
severity: normal
status: open
title: Ternary operator precedence relative to bitwise or
type: behavior
versions: Python 3.6

___
Python tracker 
<https://bugs.python.org/issue42900>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41270] NamedTemporaryFile is not its own iterator.

[Peter]

Change by Peter :


--
nosy: +maubp

___
Python tracker 
<https://bugs.python.org/issue41270>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13989] gzip always returns byte strings, no text mode

[Peter]

New submission from Peter :

Consider the following example where I have a gzipped text file,

$ python3
Python 3.2 (r32:88445, Feb 28 2011, 17:04:33) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import gzip
>>> with gzip.open("ex1.sam.gz") as handle:
... line = handle.readline()
... 
>>> line
b'EAS56_57:6:190:289:82\t69\tchr1\t100\t0\t*\t=\t100\t0\tCTCAAGGTTGTTGCAAGTCTATGTGAACAAA\t<<<7<<<;<<<<<<<<8;;<7;4<;<;94<;\tMF:i:192\n'

Notice the file was opened in binary mode ("rb" is the default for gzip.open 
which is surprising given "t" is the default for open on Python 3), and a byte 
string is returned.

Now try explicitly using non-binary reading "r", and again you get bytes rather 
than a (unicode) string as I would expect:

>>> with gzip.open("ex1.sam.gz", "r") as handle:
... line = handle.readline()
... 
>>> line
b'EAS56_57:6:190:289:82\t69\tchr1\t100\t0\t*\t=\t100\t0\tCTCAAGGTTGTTGCAAGTCTATGTGAACAAA\t<<<7<<<;<<<<<<<<8;;<7;4<;<;94<;\tMF:i:192\n'


Now try and use "t" or "rt" to be even more explicit that text mode is desired,

>>> with gzip.open("ex1.sam.gz", "t") as handle:
... line = handle.readline()
... 
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/pjcock/lib/python3.2/gzip.py", line 46, in open
return GzipFile(filename, mode, compresslevel)
  File "/Users/pjcock/lib/python3.2/gzip.py", line 157, in __init__
fileobj = self.myfileobj = builtins.open(filename, mode or 'rb')
ValueError: can't have text and binary mode at once


>>> with gzip.open("ex1.sam.gz", "rt") as handle:
... line = handle.readline()
... 
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/pjcock/lib/python3.2/gzip.py", line 46, in open
return GzipFile(filename, mode, compresslevel)
  File "/Users/pjcock/lib/python3.2/gzip.py", line 157, in __init__
fileobj = self.myfileobj = builtins.open(filename, mode or 'rb')
ValueError: can't have text and binary mode at once


See also Issue #5148 which is perhaps somewhat related.

--
components: None
messages: 153067
nosy: maubp
priority: normal
severity: normal
status: open
title: gzip always returns byte strings, no text mode
versions: Python 3.2

___
Python tracker 
<http://bugs.python.org/issue13989>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11438] 2to3 does not fix izip_longest

[Peter]

Changes by Peter :


--
nosy: +maubp

___
Python tracker 
<http://bugs.python.org/issue11438>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16258] test_local.TestEnUSCollection failures on Solaris 10

[Peter]

Peter added the comment:

I'm getting the same 2 errors in Python 3.4.6 on Solaris 11.

Comes up when you run 'gmake test' or

./python -W default -bb -E -W error::BytesWarning -m test -r -w -j 0 -v 
test_locale.py

--
nosy: +petriborg

___
Python tracker 
<http://bugs.python.org/issue16258>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29269] test_socket failing in solaris

[Peter]

Peter added the comment:

Getting the same test_socket errors on Solaris 11 with Python 3.5.3.


==
ERROR: testCount (test.test_socket.SendfileUsingSendfileTest)
--
Traceback (most recent call last):
  File "/usr/local/src/Python-3.5.3/Lib/test/test_socket.py", line 5204, in 
testCount
  File "/usr/local/src/Python-3.5.3/Lib/test/test_socket.py", line 5107, in 
recv_data
MemoryError

==
ERROR: testCount (test.test_socket.SendfileUsingSendfileTest)
--
Traceback (most recent call last):
  File "/usr/local/src/Python-3.5.3/Lib/test/test_socket.py", line 266, in 
_tearDown
  File "/usr/local/src/Python-3.5.3/Lib/test/test_socket.py", line 278, in 
clientRun
  File "/usr/local/src/Python-3.5.3/Lib/test/test_socket.py", line 5197, in 
_testCount
  File "/usr/local/src/Python-3.5.3/Lib/socket.py", line 286, in 
_sendfile_use_sendfile
raise _socket.timeout('timed out')
socket.timeout: timed out

==
ERROR: testWithTimeout (test.test_socket.SendfileUsingSendfileTest)
--
Traceback (most recent call last):
  File "/usr/local/src/Python-3.5.3/Lib/test/test_socket.py", line 5274, in 
testWithTimeout
  File "/usr/local/src/Python-3.5.3/Lib/test/test_socket.py", line 5107, in 
recv_data
MemoryError

==
ERROR: testWithTimeout (test.test_socket.SendfileUsingSendfileTest)
--
Traceback (most recent call last):
  File "/usr/local/src/Python-3.5.3/Lib/test/test_socket.py", line 266, in 
_tearDown
  File "/usr/local/src/Python-3.5.3/Lib/test/test_socket.py", line 278, in 
clientRun
  File "/usr/local/src/Python-3.5.3/Lib/test/test_socket.py", line 5269, in 
_testWithTimeout
  File "/usr/local/src/Python-3.5.3/Lib/socket.py", line 286, in 
_sendfile_use_sendfile
raise _socket.timeout('timed out')
socket.timeout: timed out

--
Ran 530 tests in 54.577s

FAILED (errors=4, skipped=315)
test test_socket failed
1 test failed again:
test_socket

--
nosy: +petriborg

___
Python tracker 
<http://bugs.python.org/issue29269>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30735] Python 3.6.1 test_asyncio fails on Solaris 11

[Peter]

New submission from Peter:

I was building all the latest Python (2.7.13, 3.4.6, 3.5.3 and 3.6.1) on 
Solaris 11 using gcc 4.9.2 and found that Python 3.6.1 test_asyncio 
consistently fails while the other versions don't.

Details:


$ ./python -W default -bb -E -W error::BytesWarning -m test -r -w -j 0 
test_asyncio
Using random seed 44984
Run tests in parallel using 10 child processes
0:00:28 [1/1/1] test_asyncio failed
Executing  took 
0.178 seconds
test test_asyncio failed -- Traceback (most recent call last):
  File "/usr/local/src/Python-3.6.1/Lib/unittest/mock.py", line 1179, in patched
return func(*args, **keywargs)
  File "/usr/local/src/Python-3.6.1/Lib/test/test_asyncio/test_base_events.py", 
line 1232, in test_create_connection_service_name
t, p = self.loop.run_until_complete(coro)
  File "/usr/local/src/Python-3.6.1/Lib/asyncio/base_events.py", line 466, in 
run_until_complete
return future.result()
  File "/usr/local/src/Python-3.6.1/Lib/asyncio/base_events.py", line 732, in 
create_connection
infos = f1.result()
  File "/usr/local/src/Python-3.6.1/Lib/concurrent/futures/thread.py", line 55, 
in run
result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/src/Python-3.6.1/Lib/socket.py", line 743, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno 9] service name not available for the specified socket 
type

1 test failed:
test_asyncio
Re-running failed tests in verbose mode
Re-running test 'test_asyncio' in verbose mode

... snipped ...

==
ERROR: test_create_connection_service_name 
(test.test_asyncio.test_base_events.BaseEventLoopWithSelectorTests)
--
Traceback (most recent call last):
  File "/usr/local/src/Python-3.6.1/Lib/unittest/mock.py", line 1179, in patched
return func(*args, **keywargs)
  File "/usr/local/src/Python-3.6.1/Lib/test/test_asyncio/test_base_events.py", 
line 1232, in test_create_connection_service_name
t, p = self.loop.run_until_complete(coro)
  File "/usr/local/src/Python-3.6.1/Lib/asyncio/base_events.py", line 466, in 
run_until_complete
return future.result()
  File "/usr/local/src/Python-3.6.1/Lib/asyncio/base_events.py", line 732, in 
create_connection
infos = f1.result()
  File "/usr/local/src/Python-3.6.1/Lib/concurrent/futures/thread.py", line 55, 
in run
result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/src/Python-3.6.1/Lib/socket.py", line 743, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno 9] service name not available for the specified socket 
type

==
ERROR: test_server_close (test.test_asyncio.test_events.PollEventLoopTests)
--
Traceback (most recent call last):
  File "/usr/local/src/Python-3.6.1/Lib/test/test_asyncio/test_events.py", line 
1340, in test_server_close
ConnectionRefusedError, client.connect, ('127.0.0.1', port))
  File "/usr/local/src/Python-3.6.1/Lib/unittest/case.py", line 728, in 
assertRaises
return context.handle('assertRaises', args, kwargs)
  File "/usr/local/src/Python-3.6.1/Lib/unittest/case.py", line 177, in handle
callable_obj(*args, **kwargs)
TimeoutError: [Errno 145] Connection timed out

==
ERROR: test_sock_client_fail (test.test_asyncio.test_events.PollEventLoopTests)
--
Traceback (most recent call last):
  File "/usr/local/src/Python-3.6.1/Lib/test/test_asyncio/test_events.py", line 
471, in test_sock_client_fail
self.loop.sock_connect(sock, address))
  File "/usr/local/src/Python-3.6.1/Lib/asyncio/base_events.py", line 466, in 
run_until_complete
return future.result()
  File "/usr/local/src/Python-3.6.1/Lib/asyncio/selector_events.py", line 451, 
in sock_connect
return (yield from fut)
  File "/usr/local/src/Python-3.6.1/Lib/asyncio/selector_events.py", line 481, 
in _sock_connect_cb
raise OSError(err, 'Connect call failed %s' % (address,))
TimeoutError: [Errno 145] Connect call failed ('127.0.0.1', 56937)

==
ERROR: test_server_close (test.test_asyncio.test_events.SelectEventLoopTests)
--
Traceback (most recent call last):
  File "/usr/local/src/Python-3.6.1/Lib/test/test_asyncio/test_events.py", line 
1340, in

[issue30012] gzip.open(filename, "rt") fails on Python 2.7.11 on win32, invalid mode rtb

[Peter]

New submission from Peter:

Under Python 2, gzip.open defaults to giving (non-unicode) strings.

Under Python 3, gzip.open defaults to giving bytes. Therefore it was fixed to 
allow text mode be specified, see http://bugs.python.org/issue13989

In order to write Python 2 and 3 compatible code to get strings from gzip, I 
now use:

>>> import gzip
>>> handle = gzip.open(filename, "rt")

In general mode="rt" works great, but I just found this fails under Windows XP 
running Python 2.7, example below using the following gzipped plain text file:

https://github.com/biopython/biopython/blob/master/Doc/examples/ls_orchid.gbk.gz

This works perfectly on Linux giving strings on both Python 2 and 3 - not I am 
printing with repr to confirm we have a string object:

$ python2.7 -c "import gzip; print(repr(gzip.open('ls_orchid.gbk.gz', 
'rt').readline())); import sys; print(sys.version)"
'LOCUS   Z78533   740 bpDNA linear   PLN 
30-NOV-2006\n'
2.7.10 (default, Sep 28 2015, 13:58:31) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-16)]

Also with a slightly newer Python 2.7,

$ /mnt/apps/python/2.7/bin/python  -c "import gzip; 
print(repr(gzip.open('ls_orchid.gbk.gz', 'rt').readline())); import sys; 
print(sys.version)"
'LOCUS   Z78533   740 bpDNA linear   PLN 
30-NOV-2006\n'
2.7.13 (default, Mar  9 2017, 15:07:48) 
[GCC 4.9.2 20150212 (Red Hat 4.9.2-6)]

$ python3.5 -c "import gzip; print(repr(gzip.open('ls_orchid.gbk.gz', 
'rt').readline())); import sys; print(sys.version)"
'LOCUS   Z78533   740 bpDNA linear   PLN 
30-NOV-2006\n'
3.5.0 (default, Sep 28 2015, 11:25:31) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-16)]

$ python3.4 -c "import gzip; print(repr(gzip.open('ls_orchid.gbk.gz', 
'rt').readline())); import sys; print(sys.version)"
'LOCUS   Z78533   740 bpDNA linear   PLN 
30-NOV-2006\n'
3.4.3 (default, Aug 21 2015, 11:12:32) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-11)]

$ python3.3 -c "import gzip; print(repr(gzip.open('ls_orchid.gbk.gz', 
'rt').readline())); import sys; print(sys.version)"
'LOCUS   Z78533   740 bpDNA linear   PLN 
30-NOV-2006\n'
3.3.0 (default, Nov  7 2012, 21:52:39) 
[GCC 4.4.6 20120305 (Red Hat 4.4.6-4)]


This works perfectly on macOS giving strings on both Python 2 and 3:


$ python2.7 -c "import gzip; print(repr(gzip.open('ls_orchid.gbk.gz', 
'rt').readline())); import sys; print(sys.version)"
'LOCUS   Z78533   740 bpDNA linear   PLN 
30-NOV-2006\n'
2.7.10 (default, Jul 30 2016, 19:40:32) 
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)]

$ python3.6 -c "import gzip; print(repr(gzip.open('ls_orchid.gbk.gz', 
'rt').readline())); import sys; print(sys.version)"
'LOCUS   Z78533   740 bpDNA linear   PLN 
30-NOV-2006\n'
3.6.0 (v3.6.0:41df79263a11, Dec 22 2016, 17:23:13) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]


This works perfectly on Python 3 running on Windows XP,


C:\repositories\biopython\Doc\examples>c:\Python33\python.exe -c "import gzip; 
print(repr(gzip.open('ls_orchid.gbk.gz', 'rt').readline()\
)); import sys; print(sys.version)"
'LOCUS   Z78533   740 bpDNA linear   PLN 
30-NOV-2006\n'
3.3.5 (v3.3.5:62cf4e77f785, Mar  9 2014, 10:37:12) [MSC v.1600 32 bit (Intel)]

C:\repositories\biopython\Doc\examples> C:\Python34\python.exe -c "import gzip; 
print(repr(gzip.open('ls_orchid.gbk.gz', 'rt').readline(\
))); import sys; print(sy
s.version)"
'LOCUS   Z78533   740 bpDNA linear   PLN 
30-NOV-2006\n'
3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 19:28:18) [MSC v.1600 32 bit (Intel)]



However, it fails on Windows XP running Python 2.7.11 and (after upgrading) 
Python 2.7.13 though:


C:\repositories\biopython\Doc\examples>c:\Python27\python -c "import sys; 
print(sys.version); import gzip; print(repr(gzip.open('ls_orch\
id.gbk.gz', 'rt').readlines()))"
2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59) [MSC v.1500 32 bit (Intel)]

Traceback (most recent call last):
  File "", line 1, in 
  File "c:\Python27\lib\gzip.py", line 34, in open
return GzipFile(filename, mode, compresslevel)
  File "c:\Python27\lib\gzip.py", line 94, in __init__
fileobj = self.myfileobj = __builtin__.open(filename, mode or 'rb')
ValueError: Invalid mode ('rtb')


Note that the strangely contradictory mode seems to be accepted by Python 2.7 
under Linux or macOS:


$ python
Python 2.7.10 (

[issue30012] gzip.open(filename, "rt") fails on Python 2.7.11 on win32, invalid mode rtb

[Peter]

Peter added the comment:

I want a simple cross platform (Linux/Mac/Windows) and cross version (Python 
2/3) way to be able to open a gzipped file and get a string handle (default 
encoding TextIOWrapper under Python 3 is fine). My use-case is specifically for 
documentation examples.

Previously I used gzip.open(filename) but with the introduction of Python 3 
that stopped working because the Python 3 default was to give you bytes.

Thanks to http://bugs.python.org/issue13989 switching to  gzip.open(filename, 
"rt") almost covered my use case, leaving Python 2 windows as the odd one out.

I propose that under Python 2.7, gzip.open explicit accept but ignore "t" as 
part of the mode argument in order to allow cross-platform code to work nicely.

i.e. Formalise the observed Python 2.7 behaviour under Linux and Mac which 
ignore the "t", and change Windows so that it ignores the "t" as well.

--

___
Python tracker 
<http://bugs.python.org/issue30012>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30012] gzip.open(filename, "rt") fails on Python 2.7.11 on win32, invalid mode rtb

[Peter]

Peter added the comment:

A workaround for my use case is even simpler, something like this:

try:
handle = gzip.open(filename, "rt")
except ValueError:
# Workaround for Python 2.7 under Windows
handle = gzip.open(filename, "r")

However, even this is troublesome for use in documentation intended to work on 
Python 2 and 3, over Linux, Mac and Windows.

--

___
Python tracker 
<http://bugs.python.org/issue30012>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30012] gzip.open(filename, "rt") fails on Python 2.7.11 on win32, invalid mode rtb

[Peter]

Peter added the comment:

OK, thanks. Given this is regarded as an enhancement rather than a bug fix, I 
understand the choice not to change this in Python 2.7.

--

___
Python tracker 
<http://bugs.python.org/issue30012>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33120] infinite loop in inspect.unwrap(unittest.mock.call)

[Peter]

New submission from Peter :

The following module will eat all available RAM if executed:

import inspect
import unittest.mock
print(inspect.unwrap(unittest.mock.call))

inspect.unwrap has loop protection against functions that wrap themselves, but 
unittest.mock.call creates new object on demand.

--
components: Library (Lib)
messages: 314254
nosy: peterdemin
priority: normal
severity: normal
status: open
title: infinite loop in inspect.unwrap(unittest.mock.call)
type: crash
versions: Python 3.6

___
Python tracker 
<https://bugs.python.org/issue33120>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33120] infinite loop in inspect.unwrap(unittest.mock.call)

[Peter]

Peter  added the comment:

I see two options to fix it:

1) add recursion depth check to inspect.wrap
2) define __wrapped__ on mock._Call so it won't go into recursion.

--

___
Python tracker 
<https://bugs.python.org/issue33120>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33999] `pip3 install past` does not work

[Peter]

New submission from Peter :

When trying to install the `past` module using pip 10.0.1 using python 3.6.5 I 
get:

$ pip3 install past --no-compile
Collecting past
  Could not find a version that satisfies the requirement past (from versions: )
No matching distribution found for past


Confirming package exists with pip search:

$ pip3 search past | grep past
past (0.11.1)- [Experimental] Run Python 2 code 
from Python 3


--
components: 2to3 (2.x to 3.x conversion tool)
messages: 320719
nosy: PeterGhimself
priority: normal
severity: normal
status: open
title: `pip3 install past` does not work
type: behavior
versions: Python 3.6

___
Python tracker 
<https://bugs.python.org/issue33999>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6715] xz compressor support

[Peter]

Peter added the comment:

Apologies for noise, but since a backport was discussed, I'm mentioning this 
here.

I've started implementing a backport, currently working and tested on Mac OS X 
and Linux, back to Python 3.0 - supporting Python 2 would be nice but probably 
significantly more work (assistance welcome - please get in touch on github):
https://github.com/peterjc/backports.lzma

Assuming Nadeem has no objections, I intend to publish this on PyPI (I have 
tried to email directly but perhaps I'm using an old email address or he has 
been busy, another reason for commenting here). Thanks!

--
nosy: +maubp

___
Python tracker 
<http://bugs.python.org/issue6715>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6715] xz compressor support

[Peter]

Peter added the comment:

Apologies again for the noise, but I've just made the first public release of 
the lzma backport at http://pypi.python.org/pypi/backports.lzma/ with the 
repository as mentioned before at https://github.com/peterjc/backports.lzma

I have tested this on Python 2.6, 2.7 and 3.0 through 3.3 under Linux and Mac 
OS. I've not tried building this on Windows yet, but it should be possible and 
I will be reviewing Amaury's notes on this thread.

My thanks to Nadeem and Per for looking over this with helpful feedback, and 
agreeing to the use of the 3-clause BSD license for the backport.

If anyone has any further questions about the backport, please get in touch via 
GitHub or email me.

--

___
Python tracker 
<http://bugs.python.org/issue6715>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19111] 2to3 should remove from future_builtins import *

[Peter]

New submission from Peter:

The 2to3 script should remove lines like this:

from future_builtins import zip

after running the zip fixer which respects the meaning of this command (issue 
217). It does not, which results in an ImportError when trying to use the 
converted code under Python 3.

Similarly for lines like this after running the map fixer etc:

from future_builtins import map

Background:

Python 2.6 and 2.7 have an iterator-style zip function in future_builtins (and 
other things):

$ python2.6
Python 2.6.8 (unknown, Sep 28 2013, 12:09:28) 
[GCC 4.6.3] on linux3
Type "help", "copyright", "credits" or "license" for more information.
>>> import future_builtins
>>> dir(future_builtins)
['__doc__', '__file__', '__name__', '__package__', 'ascii', 'filter', 'hex', 
'map', 'oct', 'zip']
>>> quit()

$ python2.7
Python 2.7.1 (r271:86832, Dec 26 2010, 19:03:20) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import future_builtins
>>> dir(future_builtins)
['__doc__', '__file__', '__name__', '__package__', 'ascii', 'filter', 'hex', 
'map', 'oct', 'zip']
>>> quit()

The future_builtins module does not exist under Python 3, in particular its zip 
and map functions do not exist.

$ python3.3
Python 3.3.2 (default, Sep 28 2013, 12:00:20) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import future_builtins
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named 'future_builtins'

--

Sample script using zip which works under Python 2.6 and 2.7,

$ more zip_2to3_bug.py 
from future_builtins import zip
assert next(zip("abc", [1, 2, 3])) == ("a", 1)
print "Done"

$ python2.6 zip_2to3_bug.py 
Done

$ python2.7 zip_2to3_bug.py 
Done

Now let's use the 2to3 script (in place):

$ 2to3 -w zip_2to3_bug.py 
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: Refactored zip_2to3_bug.py
--- zip_2to3_bug.py (original)
+++ zip_2to3_bug.py (refactored)
@@ -1,3 +1,3 @@
 from future_builtins import zip
 assert next(zip("abc", [1, 2, 3])) == ("a", 1)
-print "Done"
+print("Done")

Here's the (broken) output:

$ more zip_2to3_bug.py
from future_builtins import zip
assert next(zip("abc", [1, 2, 3])) == ("a", 1)
print("Done")

This breaks:

$ python3.3 zip_2to3_bug.py
Traceback (most recent call last):
  File "zip_2to3_bug.py", line 1, in 
from future_builtins import zip
ImportError: No module named 'future_builtins'

Expected output should respect the fact I am using "from future_builtins import 
zip" therefore zip as an iterator already (this is working), and then remove 
the line "from future_builtins import zip":

$ more zip_2to3_bug.py
assert next(zip("abc", [1, 2, 3])) == ("a", 1)
print("Done")

--


Sample script using zip which works under Python 2.6 and 2.7,

$ more map_2to3_bug.py 
from future_builtins import map
x = [-2, -1, 0, 1, 2, 3]
y = next(map(abs, x))
assert y == 2 
print "Done"

$ python2.6 map_2to3_bug.py 
Done

$ python2.7 map_2to3_bug.py 
Done

Now let's use the 2to3 script (in place):

$ 2to3 -w map_2to3_bug.py 
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: Refactored map_2to3_bug.py
--- map_2to3_bug.py (original)
+++ map_2to3_bug.py (refactored)
@@ -2,4 +2,4 @@
 x = [-2, -1, 0, 1, 2, 3]
 y = next(map(abs, x))
 assert y == 2 
-print "Done"
+print("Done")
RefactoringTool: Files that were modified:
RefactoringTool: map_2to3_bug.py

Here's the (broken) output:

$ more map_2to3_bug.py
from future_builtins import map
x = [-2, -1, 0, 1, 2, 3]
y = next(map(abs, x))
assert y == 2 
print("Done")

This breaks:

$ python3.3 map_2to3_bug.py
Traceback (most recent call last):
  File "map_2to3_bug.py", line 1, in 
from future_builtins import map
ImportError: No module named 'future_builtins'


Expected output should respect the fact I am using "from future_builtins import 
map" and the

[issue19111] 2to3 should remove from future_builtins import *

[Peter]

Peter added the comment:

Thinking about this, perhaps the bug is that Python 3 doesn't have a 
future_builtins module? Consider:


$ python2.6
Python 2.6.8 (unknown, Sep 28 2013, 12:09:28) 
[GCC 4.6.3] on linux3
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import with_statement
>>> from __future__ import print_function
>>> from future_builtins import map, zip
>>> quit()


versus:


$ python3.3
Python 3.3.2 (default, Sep 28 2013, 12:00:20) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import with_statement
>>> from __future__ import print_function
>>> from future_builtins import map, zip
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named 'future_builtins'
>>> quit()


The expectation from the __future__ imports is that once a feature is part of 
Python, the import is a harmless no-op. You could expect the same from  
future_builtins as well.

--

___
Python tracker 
<http://bugs.python.org/issue19111>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19174] Add range to future_builtins

[Peter]

New submission from Peter:

Much like how iterator style filter, map and zip are available via 
future_builtins (issue #2171), it would be natural to expect range to be there 
too, e.g.

>>> from future_builtins import range
>>> range(5)
range(0, 5)

The 2to3 fixers would need to be modified in the same way the map/filter/zip 
fixers were to be aware when a Python3 style range was in use via this import.

--
messages: 198997
nosy: maubp
priority: normal
severity: normal
status: open
title: Add range to future_builtins
type: enhancement
versions: Python 2.7

___
Python tracker 
<http://bugs.python.org/issue19174>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2734] 2to3 converts long(itude) argument to int

[Peter]

Changes by Peter :


--
nosy: +maubp

___
Python tracker 
<http://bugs.python.org/issue2734>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9257] cElementTree iterparse requires events as bytes; ElementTree uses strings

[Peter]

Changes by Peter :


--
nosy: +maubp

___
Python tracker 
<http://bugs.python.org/issue9257>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name

[Peter]

Peter  added the comment:

I take it the IGNORE_EXCEPTION_DETAIL should ignore the module name
fix will not be applied to Python 3.1.x?

Is there a separate bug to enhance 2to3 to turn IGNORE_EXCEPTION_DETAIL
on?

--
nosy: +maubp

___
Python tracker 
<http://bugs.python.org/issue7490>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9217] 2to3 crashes with some doctests

[Peter]

Changes by Peter :


--
nosy: +maubp

___
Python tracker 
<http://bugs.python.org/issue9217>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9217] 2to3 doctests

[Peter]

Changes by Peter :


--
title: 2to3 crashes with some doctests -> 2to3 doctests

___
Python tracker 
<http://bugs.python.org/issue9217>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9217] 2to3 crashes with some doctests

[Peter]

Peter  added the comment:

Reverted accidental title change - had keyboard focus on the page not
the address bar I think. Sorry!

--
title: 2to3 doctests -> 2to3 crashes with some doctests

___
Python tracker 
<http://bugs.python.org/issue9217>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17666] Extra gzip headers breaks _read_gzip_header

[Peter]

New submission from Peter:

Regression in Python 3.3.0 to 3.3.1, tested under Mac OS X 10.8 and CentOS 
Linux 64bit.

The same regression also present in going from Python 2.7.3 from 2.7.4, does 
that need a separate issue filed?

Consider this VALID GZIP file, human link:
https://github.com/biopython/biopython/blob/master/Tests/GenBank/cor6_6.gb.bgz

Binary link, only a small file:
https://raw.github.com/biopython/biopython/master/Tests/GenBank/cor6_6.gb.bgz

This is compressed using a GZIP variant called BGZF which uses multiple blocks 
and records additional tags in the header, for background see:
http://blastedbio.blogspot.com/2011/11/bgzf-blocked-bigger-better-gzip.html

$ curl -O 
https://raw.github.com/biopython/biopython/master/Tests/GenBank/cor6_6.gb.bgz
$ cat cor6_6.gb.bgz | gunzip | wc
 3201183   14967

Now for the bug, expected behaviour:

$ python3.2
Python 3.2 (r32:88445, Feb 28 2011, 17:04:33) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import gzip
>>> handle = gzip.open("cor6_6.gb.bgz", "rb")
>>> data = handle.read()
>>> handle.close()
>>> len(data)
14967
>>> quit()

Broken behaviour:

$ python3.3
Python 3.3.1 (default, Apr  8 2013, 17:54:08) 
[GCC 4.2.1 Compatible Apple Clang 4.0 ((tags/Apple/clang-421.0.57))] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import gzip
>>> handle = gzip.open("cor6_6.gb.bgz", "rb")
>>> data = handle.read()
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/pjcock/lib/python3.3/gzip.py", line 359, in read
while self._read(readsize):
  File "/Users/pjcock/lib/python3.3/gzip.py", line 432, in _read
if not self._read_gzip_header():
  File "/Users/pjcock/lib/python3.3/gzip.py", line 305, in _read_gzip_header
self._read_exact(struct.unpack("
<http://bugs.python.org/issue17666>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17666] Extra gzip headers breaks _read_gzip_header

[Peter]

Peter added the comment:

Reopening: The same regression issue affects Python 3.2.4 as well, so if the 
fix could be committed to that branch as well that would be great.

Long term, I infer that there are no GZIP files in the test suite which use the 
GZIP header to store metadata (otherwise this bug would have been caught 
earlier). Should that be raised as a separate issue? I can prepare a very small 
test file if you like and attach it here.

--
status: closed -> open
versions: +Python 3.2

___
Python tracker 
<http://bugs.python.org/issue17666>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21872] LZMA library sometimes fails to decompress a file

[Peter]

Changes by Peter :


--
nosy: +maubp

___
Python tracker 
<http://bugs.python.org/issue21872>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19746] No introspective way to detect ModuleImportFailure in unittest

[Peter]

Peter added the comment:

This comment is just to note that this change broke our (exotic?) usage of 
unittest.TestLoader().loadTestsFromName(name) inside a try/except since under 
Python 3.5 some expected exceptions are no longer raised.

My nasty workaround hack:
https://github.com/biopython/biopython/commit/929fbfbcf2d1ba65ec460a413128dd5e6f68f5bf

I think it is unfortunate that the .errors attribute is just a list of messages 
as strings, rather than the original exception object(s) which would be easier 
to handle (e.g. using the subclass hierarchy).

--
nosy: +maubp

___
Python tracker 
<http://bugs.python.org/issue19746>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25144] 3.5 Win install fails with "TARGETDIR"

[Peter]

Peter added the comment:

We just hit this bug with "The TARGETDIR variable must be provided when 
invoking this installer" and an OK button (only) on a colleagues' machine.

We first tried 
https://www.python.org/ftp/python/3.5.0/python-3.5.0-webinstall.exe (default 
options) and then https://www.python.org/ftp/python/3.5.0/python-3.5.0.exe 
(default options plus checked add to PATH) with the same problem.

My colleague recalls having previously installed and then removed Python 3.5 on 
this machine (possibly a pre-release or beta version). Could anything in the 
registry or on left disk trigger this?

--
nosy: +maubp

___
Python tracker 
<http://bugs.python.org/issue25144>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26499] http.client.IncompleteRead from HTTPResponse read after part reading file

[Peter]

New submission from Peter:

This is a regression in Python 3.5 tested under Linux and Mac OS X, spotted 
from a failing test in Biopython 
https://github.com/biopython/biopython/issues/773 where we would parse a file 
from the internet. The trigger is partially reading the network handle line by 
line (e.g. until an end record marker is found), and then calling handle.read() 
to fetch any remaining data. Self contained examples below.

Note that partially reading a file like this still works:


$ python3.5
Python 3.5.0 (default, Sep 14 2015, 12:13:24) 
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> from urllib.request import urlopen
>>> handle = urlopen("http://www.python.org";)
>>> chunk = handle.read(50)
>>> rest = handle.read()
>>> handle.close()


However, the following variants read a few lines and then attempt to call 
handle.read() and fail. The URL is not important (as long as it has over four 
lines in these examples).

Using readline,


>>> from urllib.request import urlopen
>>> handle = urlopen("http://www.python.org";)
>>> for i in range(4):
... line = handle.readline()
... 
>>> rest = handle.read()
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/xxx/lib/python3.5/http/client.py", line 446, in read
s = self._safe_read(self.length)
  File "/Users/xxx/lib/python3.5/http/client.py", line 594, in _safe_read
raise IncompleteRead(b''.join(s), amt)
http.client.IncompleteRead: IncompleteRead(46698 bytes read, 259 more expected)


Using line iteration via next,


>>> from urllib.request import urlopen
>>> handle = urlopen("http://www.python.org";)
>>> for i in range(4):
...  line = next(handle)
... 
>>> rest = handle.read()
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/xxx/lib/python3.5/http/client.py", line 446, in read
s = self._safe_read(self.length)
  File "/Users/xxx/lib/python3.5/http/client.py", line 594, in _safe_read
raise IncompleteRead(b''.join(s), amt)
http.client.IncompleteRead: IncompleteRead(46698 bytes read, 259 more expected)


Using line iteration directly,


>>> from urllib.request import urlopen
>>> count = 0
>>> handle = urlopen("http://www.python.org";)
>>> for line in handle:
... count += 1
... if count == 4:
... break
... 
>>> rest = handle.read()
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/xxx/lib/python3.5/http/client.py", line 446, in read
s = self._safe_read(self.length)
  File "/Users/xxx/lib/python3.5/http/client.py", line 594, in _safe_read
raise IncompleteRead(b''.join(s), amt)
http.client.IncompleteRead: IncompleteRead(46698 bytes read, 259 more expected)



These examples all worked on Python 3.3 and 3.4 so this is a regression.

--
components: Library (Lib)
messages: 261287
nosy: maubp
priority: normal
severity: normal
status: open
title: http.client.IncompleteRead from HTTPResponse read after part reading file
type: behavior
versions: Python 3.5

___
Python tracker 
<http://bugs.python.org/issue26499>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23786] test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error

[Peter]

New submission from Peter:

I compiled Python 3.4.3 on Solaris 11, and when I ran the regression test, I 
get a core dump when the hash() function was being used. I went through the bug 
database looking for something similar but couldn't find anything.

Tests like:
test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python 
error: Bus error

Current thread 0x0001 (most recent call first):
  File "/usr/local/lib/python3.4/test/test_hash.py", line 89 in 
test_unaligned_buffers
  File "/usr/local/lib/python3.4/unittest/case.py", line 577 in run
  File "/usr/local/lib/python3.4/unittest/case.py", line 625 in __call__
  File "/usr/local/lib/python3.4/unittest/suite.py", line 122 in run
  File "/usr/local/lib/python3.4/unittest/suite.py", line 84 in __call__
  File "/usr/local/lib/python3.4/unittest/suite.py", line 122 in run
  File "/usr/local/lib/python3.4/unittest/suite.py", line 84 in __call__
  File "/usr/local/lib/python3.4/unittest/suite.py", line 122 in run
  File "/usr/local/lib/python3.4/unittest/suite.py", line 84 in __call__
  File "/usr/local/lib/python3.4/unittest/runner.py", line 168 in run
  File "/usr/local/lib/python3.4/test/support/__init__.py", line 1769 in 
_run_suite
  File "/usr/local/lib/python3.4/test/support/__init__.py", line 1803 in 
run_unittest
  File "/usr/local/lib/python3.4/test/regrtest.py", line 1279 in test_runner
  File "/usr/local/lib/python3.4/test/regrtest.py", line 1280 in runtest_inner
  File "/usr/local/lib/python3.4/test/regrtest.py", line 978 in runtest
  File "/usr/local/lib/python3.4/test/regrtest.py", line 763 in main
  File "/usr/local/lib/python3.4/test/regrtest.py", line 1564 in 
main_in_temp_cwd
  File "/usr/local/lib/python3.4/test/__main__.py", line 3 in 
  File "/usr/local/lib/python3.4/runpy.py", line 85 in _run_code
  File "/usr/local/lib/python3.4/runpy.py", line 170 in _run_module_as_main
Bus Error (core dumped)


and


test_hash_equality (test.datetimetester.TestTime_Fast) ... Fatal Python error: 
Bus error

Current thread 0x0001 (most recent call first):
  File "/usr/local/lib/python3.4/test/datetimetester.py", line 2155 in 
test_hash_equality
  File "/usr/local/lib/python3.4/unittest/case.py", line 577 in run
  File "/usr/local/lib/python3.4/unittest/case.py", line 625 in __call__
  File "/usr/local/lib/python3.4/unittest/suite.py", line 122 in run
  File "/usr/local/lib/python3.4/unittest/suite.py", line 84 in __call__
  File "/usr/local/lib/python3.4/unittest/suite.py", line 122 in run
  File "/usr/local/lib/python3.4/unittest/suite.py", line 84 in __call__
  File "/usr/local/lib/python3.4/unittest/runner.py", line 168 in run
  File "/usr/local/lib/python3.4/test/support/__init__.py", line 1769 in 
_run_suite
  File "/usr/local/lib/python3.4/test/support/__init__.py", line 1803 in 
run_unittest
  File "/usr/local/lib/python3.4/test/test_datetime.py", line 45 in test_main
  File "/usr/local/lib/python3.4/test/regrtest.py", line 1280 in runtest_inner
  File "/usr/local/lib/python3.4/test/regrtest.py", line 978 in runtest
  File "/usr/local/lib/python3.4/test/regrtest.py", line 763 in main
  File "/usr/local/lib/python3.4/test/regrtest.py", line 1564 in 
main_in_temp_cwd
  File "/usr/local/lib/python3.4/test/__main__.py", line 3 in 
  File "/usr/local/lib/python3.4/runpy.py", line 85 in _run_code
  File "/usr/local/lib/python3.4/runpy.py", line 170 in _run_module_as_main
Bus Error (core dumped)



I then ran the same test through gdb:
$ gdb /usr/local/bin/python3.4
GNU gdb (GDB) 7.8.1

(gdb) run -m test -v test_hash
Starting program: /usr/local/bin/python3.4 -m test -v test_hash
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
== CPython 3.4.3 (default, Mar 25 2015, 17:35:25) [GCC 4.6.2]
==   Solaris-2.11-sun4v-sparc-32bit-ELF big-endian
==   hash algorithm: fnv 32bit
==   /tmp/test_python_12329
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, 
dont_write_bytecode=0, no_user_site=0, no_
site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, 
hash_randomization=1, isolated=0)
[1/1] test_hash
test_empty_string (test.test_hash.BytesHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_long_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_null_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.DatetimeDateTests) ... ok
test_randomized_hash (test.test_hash.DatetimeDatetimeTests) ... FAIL
test_ra

[issue23786] test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error

[Peter]

Peter added the comment:

I went and recompiled with:
$ ./configure --prefix=/usr/local --enable-shared 
--with-hash-algorithm=siphash24

But this crashed as well.

test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python 
error: Bus error

Current thread 0x0001 (most recent call first):
  File "/usr/local/src/Python-3.4.3/Lib/test/test_hash.py", line 89 in 
test_unaligned_buffers
  File "/usr/local/src/Python-3.4.3/Lib/unittest/case.py", line 577 in run
  File "/usr/local/src/Python-3.4.3/Lib/unittest/case.py", line 625 in __call__
  File "/usr/local/src/Python-3.4.3/Lib/unittest/suite.py", line 122 in run
  File "/usr/local/src/Python-3.4.3/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/local/src/Python-3.4.3/Lib/unittest/suite.py", line 122 in run
  File "/usr/local/src/Python-3.4.3/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/local/src/Python-3.4.3/Lib/unittest/suite.py", line 122 in run
  File "/usr/local/src/Python-3.4.3/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/local/src/Python-3.4.3/Lib/unittest/runner.py", line 168 in run
  File "/usr/local/src/Python-3.4.3/Lib/test/support/__init__.py", line 1769 in 
_run_suite
  File "/usr/local/src/Python-3.4.3/Lib/test/support/__init__.py", line 1803 in 
run_unittest
  File "/usr/local/src/Python-3.4.3/Lib/test/regrtest.py", line 1279 in 
test_runner
  File "/usr/local/src/Python-3.4.3/Lib/test/regrtest.py", line 1280 in 
runtest_inner
  File "/usr/local/src/Python-3.4.3/Lib/test/regrtest.py", line 978 in runtest
  File "/usr/local/src/Python-3.4.3/Lib/test/regrtest.py", line 763 in main
  File "/usr/local/src/Python-3.4.3/Lib/test/regrtest.py", line 1564 in 
main_in_temp_cwd
  File "/usr/local/src/Python-3.4.3/Lib/test/__main__.py", line 3 in 
  File "/usr/local/src/Python-3.4.3/Lib/runpy.py", line 85 in _run_code
  File "/usr/local/src/Python-3.4.3/Lib/runpy.py", line 170 in 
_run_module_as_main
Bus Error (core dumped)


test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xff25d3d8 in siphash24 (src=0x1d2809, src_sz=) at 
Python/pyhash.c:387
387 PY_UINT64_T mi = _le64toh(*in);
(gdb) bt
#0  0xff25d3d8 in siphash24 (src=0x1d2809, src_sz=) at 
Python/pyhash.c:387
#1  0xff25dfa0 in _Py_HashBytes (src=0x1d2809, len=127) at Python/pyhash.c:186
#2  0xff1a7ce4 in memory_hash (self=0xfdfc5dc0) at Objects/memoryobject.c:2793
#3  0xff1afa40 in PyObject_Hash (v=0xfdfc5dc0) at Objects/object.c:757
#4  0xff22b6fc in builtin_hash (self=0xfee23600, v=0xfdfc5dc0) at 
Python/bltinmodule.c:1269
#5  0xff236a70 in call_function (oparg=, pp_stack=0xffbfcd64) at 
Python/ceval.c:4224
#6  PyEval_EvalFrameEx (f=, throwflag=) at 
Python/ceval.c:2838
#7  0xff237790 in fast_function (nk=, na=, n=1, 
pp_stack=0xffbfce5c,
func=) at Python/ceval.c:4334


(gdb) list
382 PY_UINT64_T t;
383 PY_UINT8_T *pt;
384 PY_UINT8_T *m;
385
386 while (src_sz >= 8) {
387 PY_UINT64_T mi = _le64toh(*in);
388 in += 1;
389 src_sz -= 8;
390 v3 ^= mi;
391 DOUBLE_ROUND(v0,v1,v2,v3);

--

___
Python tracker 
<http://bugs.python.org/issue23786>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23786] test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error

[Peter]

Peter added the comment:

I've compiled Python 3.3.6 using the same options (./configure 
--prefix=/usr/local --enable-shared) and build system and that passes almost 
all the tests (test_uuid fails for an ignorable reason).

Specifically test_hash passes fully:

$ LD_LIBRARY_PATH=/usr/local/src/Python-3.3.6 ./python -m test -v test_hash
== CPython 3.3.6 (default, Mar 26 2015, 15:35:36) [GCC 4.6.2]
==   Solaris-2.11-sun4v-sparc-32bit-ELF big-endian
==   /usr/local/src/Python-3.3.6/build/test_python_4539
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, 
dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, 
verbose=0, bytes_warning=0, quiet=0, hash_randomization=1)
[1/1] test_hash
test_empty_string (test.test_hash.BytesHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_null_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.DatetimeDateTests) ... ok
test_randomized_hash (test.test_hash.DatetimeDatetimeTests) ... ok
test_randomized_hash (test.test_hash.DatetimeTimeTests) ... ok
test_hashes (test.test_hash.HashBuiltinsTestCase) ... ok
test_coerced_floats (test.test_hash.HashEqualityTestCase) ... ok
test_coerced_integers (test.test_hash.HashEqualityTestCase) ... ok
test_numeric_literals (test.test_hash.HashEqualityTestCase) ... ok
test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... ok
test_default_hash (test.test_hash.HashInheritanceTestCase) ... ok
test_error_hash (test.test_hash.HashInheritanceTestCase) ... ok
test_fixed_hash (test.test_hash.HashInheritanceTestCase) ... ok
test_hashable (test.test_hash.HashInheritanceTestCase) ... ok
test_not_hashable (test.test_hash.HashInheritanceTestCase) ... ok
test_empty_string (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_null_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_empty_string (test.test_hash.StrHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.StrHashRandomizationTests) ... ok
test_null_hash (test.test_hash.StrHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.StrHashRandomizationTests) ... ok

--
Ran 25 tests in 1.356s

OK
1 test OK.


So any ideas what I should look for? Or perhaps it would be helpful if I posted 
config.log, etc.

--

___
Python tracker 
<http://bugs.python.org/issue23786>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23786] test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error

[Peter]

Peter added the comment:

That's not a valid option on SPARC, (see 
https://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html ) the flag is only 
available on ARM it seems.

--

___
Python tracker 
<http://bugs.python.org/issue23786>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23786] test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error

[Peter]

Peter added the comment:

OK I recompiled with "./configure --prefix=/usr/local --enable-shared 
--with-pydebug" and reran the test, unfortunately...

$ LD_LIBRARY_PATH=/usr/local/src/Python-3.4.3 ./python -m test  test_hash
[1/1] test_hash
1 test OK.


I then applied the patch in msg239385, this resulted in the same crash, I 
couldn't see any difference in gdb.

I then tried each of the patches in msg239384, with -munaligned-doubles and 
with -mnounaligned-doubles, again no difference.

I did notice that two tests failed in test_hash prior to the core dump, so here 
are the outputs from those in case that helps.

<3.4.3 ./python -m test  -v test_hash.DatetimeDatetimeTests 
test_hash.DatetimeTimeTests
== CPython 3.4.3 (default, Mar 27 2015, 08:45:04) [GCC 4.6.2]
==   Solaris-2.11-sun4v-sparc-32bit-ELF big-endian
==   hash algorithm: fnv 32bit
==   /usr/local/src/Python-3.4.3/build/test_python_10340
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, 
dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, 
verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[1/2] test_hash.DatetimeDatetimeTests
test test_hash.DatetimeDatetimeTests crashed -- Traceback (most recent call 
last):
  File "", line 2218, in _find_and_load_unlocked
AttributeError: 'module' object has no attribute '__path__'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/src/Python-3.4.3/Lib/test/regrtest.py", line 1271, in 
runtest_inner
the_module = importlib.import_module(abstest)
  File "/usr/local/src/Python-3.4.3/Lib/importlib/__init__.py", line 109, in 
import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 2254, in _gcd_import
  File "", line 2237, in _find_and_load
  File "", line 2221, in _find_and_load_unlocked
ImportError: No module named 'test.test_hash.DatetimeDatetimeTests'; 
'test.test_hash' is not a package

[2/2/1] test_hash.DatetimeTimeTests
test test_hash.DatetimeTimeTests crashed -- Traceback (most recent call last):
  File "", line 2218, in _find_and_load_unlocked
AttributeError: 'module' object has no attribute '__path__'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/src/Python-3.4.3/Lib/test/regrtest.py", line 1271, in 
runtest_inner
the_module = importlib.import_module(abstest)
  File "/usr/local/src/Python-3.4.3/Lib/importlib/__init__.py", line 109, in 
import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 2254, in _gcd_import
  File "", line 2237, in _find_and_load
  File "", line 2221, in _find_and_load_unlocked
ImportError: No module named 'test.test_hash.DatetimeTimeTests'; 
'test.test_hash' is not a package

2 tests failed:
test_hash.DatetimeDatetimeTests test_hash.DatetimeTimeTests



Thanks guys!

--

___
Python tracker 
<http://bugs.python.org/issue23786>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23786] test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error

[Peter]

Peter added the comment:

Sorry I copied the wrong term buffer :-)
This is the output after I commented out the HashEqualityTestCase class which 
causes the core dump.

LD_LIBRARY_PATH=/usr/local/src/Python-3.4.3 ./python -m test -v test_hash
== CPython 3.4.3 (default, Mar 27 2015, 08:45:04) [GCC 4.6.2]
==   Solaris-2.11-sun4v-sparc-32bit-ELF big-endian
==   hash algorithm: fnv 32bit
==   /usr/local/src/Python-3.4.3/build/test_python_10730
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, 
dont_write_bytecode=0, no_user_site=0, no_
site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, 
hash_randomization=1, isolated=0)
[1/1] test_hash
test_empty_string (test.test_hash.BytesHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_long_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_null_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.DatetimeDateTests) ... ok
test_randomized_hash (test.test_hash.DatetimeDatetimeTests) ... FAIL
test_randomized_hash (test.test_hash.DatetimeTimeTests) ... FAIL
test_hashes (test.test_hash.HashBuiltinsTestCase) ... ok
test_hash_distribution (test.test_hash.HashDistributionTestCase) ... ok
test_default_hash (test.test_hash.HashInheritanceTestCase) ... ok
test_error_hash (test.test_hash.HashInheritanceTestCase) ... ok
test_fixed_hash (test.test_hash.HashInheritanceTestCase) ... ok
test_hashable (test.test_hash.HashInheritanceTestCase) ... ok
test_not_hashable (test.test_hash.HashInheritanceTestCase) ... ok
test_empty_string (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_long_fixed_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_null_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_empty_string (test.test_hash.StrHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.StrHashRandomizationTests) ... ok
test_long_fixed_hash (test.test_hash.StrHashRandomizationTests) ... ok
test_null_hash (test.test_hash.StrHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.StrHashRandomizationTests) ... ok
test_ucs2_string (test.test_hash.StrHashRandomizationTests) ... ok

==
FAIL: test_randomized_hash (test.test_hash.DatetimeDatetimeTests)
--
Traceback (most recent call last):
  File "/usr/local/src/Python-3.4.3/Lib/test/test_hash.py", line 193, in 
test_randomized_hash
run1 = self.get_hash(self.repr_, seed='random')
  File "/usr/local/src/Python-3.4.3/Lib/test/test_hash.py", line 187, in 
get_hash
**env)
  File "/usr/local/src/Python-3.4.3/Lib/test/script_helper.py", line 106, in 
assert_python_ok
return _assert_python(True, *args, **env_vars)
  File "/usr/local/src/Python-3.4.3/Lib/test/script_helper.py", line 92, in 
_assert_python
err.decode('ascii', 'ignore')))
AssertionError: Process return code is -10, command line was: 
['/usr/local/src/Python-3.4.3/python', '-X', 'faulthandle
r', '-c', 'import datetime; print(hash(datetime.datetime(1, 2, 3, 4, 5, 6, 
7)))'], stderr follows:
Fatal Python error: Bus error

Current thread 0x0001 (most recent call first):
  File "", line 1 in 

==
FAIL: test_randomized_hash (test.test_hash.DatetimeTimeTests)
--
Traceback (most recent call last):
  File "/usr/local/src/Python-3.4.3/Lib/test/test_hash.py", line 193, in 
test_randomized_hash
run1 = self.get_hash(self.repr_, seed='random')
  File "/usr/local/src/Python-3.4.3/Lib/test/test_hash.py", line 187, in 
get_hash
**env)
  File "/usr/local/src/Python-3.4.3/Lib/test/script_helper.py", line 106, in 
assert_python_ok
return _assert_python(True, *args, **env_vars)
  File "/usr/local/src/Python-3.4.3/Lib/test/script_helper.py", line 92, in 
_assert_python
err.decode('ascii', 'ignore')))
AssertionError: Process return code is -10, command line was: 
['/usr/local/src/Python-3.4.3/python', '-X', 'faulthandle
r', '-c', 'import datetime; print(hash(datetime.time(0, 0)))'], stderr follows:
Fatal Python error: Bus error

Current thread 0x0001 (most recent call first):
  File "", line 1 in 

--
Ran 26 tests in 3.429s

FAILED (failures=2)
test

[issue23786] test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error

[Peter]

Peter added the comment:

Hi haypo,

I just realized you had created a patch too, the fnv_memcpy.patch worked!

$ LD_LIBRARY_PATH=/usr/local/src/Python-3.4.3 ./python -m test test_hash
[1/1] test_hash
1 test OK.

Running the full regression test now, but I bet everything passes.

--

___
Python tracker 
<http://bugs.python.org/issue23786>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23786] test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error

[Peter]

Peter added the comment:

So this morning I got around to rebuilding the tool chain using GCC 4.9.2 and 
I'm happy to report that this problem goes away (no patch required)! So it must 
be some sort of problem with the 4.6 GCC.

I've still got the old tool chain around, and I'm happy to further patch / test 
if anyone at Python wants me to.

$ gcc --verbose
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sparc-sun-solaris2.11/4.9.2/lto-wrapper
Target: sparc-sun-solaris2.11
Configured with: ../gcc-4.9.2/configure --prefix=/usr/local 
--enable-languages=c,c++ --disable-nls --with-gnu-as --with-gnu-ld 
--target=sparc-sun-solaris2.11
Thread model: posix
gcc version 4.9.2 (GCC)

--

___
Python tracker 
<http://bugs.python.org/issue23786>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23786] test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error

[Peter]

Peter added the comment:

Test 1
Python 3.4.3 built by GCC 4.9.2 is:
>>> str(memoryview(b'abcdefghijklmnopqrstuvwxyz')[1:], 'ascii')
'bcdefghijklmnopqrstuvwxyz'


Test 2
Python 3.4.3 built by GCC 4.6.2 is (no patches applied)
This build will core dump if I run -m test test_hash.
>>> str(memoryview(b'abcdefghijklmnopqrstuvwxyz')[1:], 'ascii')
'bcdefghijklmnopqrstuvwxyz'

--

___
Python tracker 
<http://bugs.python.org/issue23786>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28660] TextWrapper break_long_words=True, break_on_hyphens=True on long words

[Peter]

New submission from Peter:

Quoting https://docs.python.org/2/library/textwrap.html

width (default: 70) The maximum length of wrapped lines. As long as there are 
no individual words in the input text longer than width, TextWrapper guarantees 
that no output line will be longer than width characters.

It appears that with break_long_words=True and break_on_hyphens=True, any 
hyphenated term longer than the specified width does not get preferentially 
broken at a hyphen.

Example input:

We used the enyzme 2-succinyl-6-hydroxy-2,4-cyclohexadiene-1-carboxylate 
synthase.


Using break_long_words=True, break_on_hyphens=True
==
We used the enyzme 2-succinyl-6-hydroxy-2,4-cycloh
exadiene-1-carboxylate synthase.
==


Expected result using break_long_words=True, break_on_hyphens=True
==
We used the enyzme 2-succinyl-6-hydroxy-2,4-
cyclohexadiene-1-carboxylate synthase.
==


Given a width=50, then the 53 character long "word" of 
"2-succinyl-6-hydroxy-2,4-cyclohexadiene-1-carboxylate" must be split 
somewhere, and since break_on_hyphens=True it should break at a hyphen as shown 
above as the desired output.


Sample code:


import textwrap
w = 50
text = "We used the enyzme 
2-succinyl-6-hydroxy-2,4-cyclohexadiene-1-carboxylate synthase."
print("Input:")
print("=" * w)
print(text)
print("=" * w)
print("Using break_long_words=True, break_on_hyphens=True")
print("=" * w)
print(textwrap.fill(text, width=w, break_long_words=True, 
break_on_hyphens=True))
print("=" * w)

--
messages: 280522
nosy: maubp
priority: normal
severity: normal
status: open
title: TextWrapper break_long_words=True, break_on_hyphens=True on long words
versions: Python 2.7

___
Python tracker 
<http://bugs.python.org/issue28660>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46153] closure fails in exec when locals is given

[Quentin Peter]

New submission from Quentin Peter :

When both namespace arguments are given to exec, function definitions fail to 
capture closure. See below:
```
Python 3.8.6 (default, Oct  8 2020, 14:06:32) 
[Clang 12.0.0 (clang-1200.0.32.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> exec("a = 1\ndef f(): return a\nprint(f())")
1
>>> exec("a = 1\ndef f(): return a\nprint(f())", {})
1
>>> exec("a = 1\ndef f(): return a\nprint(f())", {}, {})
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in 
  File "", line 2, in f
NameError: name 'a' is not defined
>>> 
```

--
messages: 409038
nosy: qpeter
priority: normal
severity: normal
status: open
title: closure fails in exec when locals is given
type: crash
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue46153>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46153] closure fails in exec when locals is given

[Quentin Peter]

Quentin Peter  added the comment:

This might be related to https://bugs.python.org/issue41918

--

___
Python tracker 
<https://bugs.python.org/issue46153>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46153] function fails in exec when locals is given

[Quentin Peter]

Quentin Peter  added the comment:

The reason I am asking is that I am working on a debugger. The debugger stops 
on a frame which is inside a function. Let's say the locals is:
locals() == {"a": 1}
I now want to define a closure with exec. I might want to do something like:
exec("def f(): return a", globals(), locals())
But this doesn't work because of the issue I describe.I would expect f() to 
look for a in the locals().

Even more surprising is that if I use the second argument of exec, the code in 
the above comment starts to fail.

--

___
Python tracker 
<https://bugs.python.org/issue46153>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46153] function fails in exec when locals is given

[Quentin Peter]

Quentin Peter  added the comment:

Thank you for your explaination. Just to be sure, it is expected that:

exec("a = 1\ndef f(): return a\nprint(f())", {})

Runs successfully but

exec("a = 1\ndef f(): return a\nprint(f())", {}, {})

Doesn't?

--

___
Python tracker 
<https://bugs.python.org/issue46153>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46153] function fails in exec when locals is given

[Quentin Peter]

Quentin Peter  added the comment:

Maybe a note could be added to 
https://docs.python.org/3/library/functions.html#exec

Something along the lines of:

Note: If exec gets two separate objects as `globals` and `locals`, the code 
will not be executed as if it were embedded in a function definition. For 
example, any function or comprehension defined at the top level will not have 
access to the `locals` scope.

PS: It would be nice for my usecase to have a way around this, maybe a flag in 
`compile` or `exec` that would produce "function code" instead of "module 
code". My workaround for this problem consist in wrapping my code in a function 
definition.

I think this means https://bugs.python.org/issue41918 should be closed as well?

--

___
Python tracker 
<https://bugs.python.org/issue46153>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

[Peter Roelants]

Peter Roelants  added the comment:

If I understand correctly this should be fixed? In which 3.10.* version should 
this be fixed?

The reason why I'm asking is that I ran into this issue when using Dask 
(2022.02.0) with multithreading on Python 3.10.2:

Exception in thread Profile:
Traceback (most recent call last):
  File "./lib/python3.10/site-packages/distributed/profile.py", line 115, in 
process
d = state["children"][ident]
KeyError: '_all_objs;./lib/python3.10/site-packages/bokeh/embed/bundle.py;357'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./lib/python3.10/threading.py", line 1009, in _bootstrap_inner
self.run()
  File "./lib/python3.10/threading.py", line 946, in run
self._target(*self._args, **self._kwargs)
  File "./lib/python3.10/site-packages/distributed/profile.py", line 274, in 
_watch
process(frame, None, recent, omit=omit)
  File "./lib/python3.10/site-packages/distributed/profile.py", line 119, in 
process
"description": info_frame(frame),
  File "./lib/python3.10/site-packages/distributed/profile.py", line 72, in 
info_frame
line = linecache.getline(co.co_filename, frame.f_lineno, 
frame.f_globals).lstrip()
  File "./lib/python3.10/linecache.py", line 31, in getline
if 1 <= lineno <= len(lines):
TypeError: '<=' not supported between instances of 'int' and 'NoneType'

--
nosy: +peter.roelants
versions: +Python 3.10 -Python 3.11

___
Python tracker 
<https://bugs.python.org/issue6>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1599254] mailbox: other programs' messages can vanish without trace

[Peter Lloyd]

Changes by Peter Lloyd:


--
nosy: +peter.ll

_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1599254>
_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1211] cleanup patch for 3.0 tutorial/interpreter.rst

[Peter Harris]

New submission from Peter Harris:

Proposed cleanup patch for tutorial/interpreter.rst

--
components: Documentation
files: interpreter.diff
messages: 56164
nosy: scav
severity: normal
status: open
title: cleanup patch for 3.0 tutorial/interpreter.rst
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1211>
__

interpreter.diff
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1212] 3.0 tutorial/introduction.rst mentions 'long'

[Peter Harris]

New submission from Peter Harris:

Remove reference to 'long' in tutorial/introduction.rst.
Patch attached.

--
components: Documentation
files: introduction.diff
messages: 56165
nosy: scav
severity: normal
status: open
title: 3.0 tutorial/introduction.rst mentions 'long'
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1212>
__

introduction.diff
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1213] 3.0 tutorial/classes.rst patch

[Peter Harris]

New submission from Peter Harris:

I think this wording is a little clearer and removes implied reference
to earlier Python versions, while still giving a simplistic
tutorial-level idea of what the MRO is. YMMV, so please disregard if
I've made it worse.

--
components: Documentation
files: classes.diff
messages: 56166
nosy: scav
severity: normal
status: open
title: 3.0 tutorial/classes.rst patch
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1213>
__

classes.diff
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1219] 3.0 library/stdtypes.rst patch

[Peter Harris]

New submission from Peter Harris:

Cleanup (removal of 2.x references, long etc. ).  I'm not 100% sure I've
got the rich-comparison stuff correct.

--
components: Documentation
files: stdtypes.diff
messages: 56186
nosy: scav
severity: normal
status: open
title: 3.0 library/stdtypes.rst patch
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1219>
__

stdtypes.diff
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1228] 3.0 tutorial/datastructures.rst patch

[Peter Harris]

New submission from Peter Harris:

Describe 3.0 comparison behaviour (but not in much detail)

--
components: Documentation
files: datastructures.diff
messages: 56212
nosy: scav
severity: normal
status: open
title: 3.0 tutorial/datastructures.rst patch
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1228>
__

datastructures.diff
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1229] 3.0 library/stdtypes.rst

[Peter Harris]

New submission from Peter Harris:

line 221 'loating point' -> 'Floating point'.

Also, maybe double-check that __cmp__ method still has special meaning
in 3.0.  My last patch took out mention of it because 3.0a1 seems not to
support comparisons using __cmp__ method, but I could be missing something.

--
components: Documentation
messages: 56213
nosy: scav
severity: minor
status: open
title: 3.0 library/stdtypes.rst
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1229>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1372] zlibmodule.c: int overflow in PyZlib_decompress

[Peter Weseloh]

New submission from Peter Weseloh:

When I use zlib.decompress to decompress a string where the result would
be >1 GB I get
SystemError: Objects/stringobject.c:4089: bad argument to internal function

I tracked that down to an int overflow of r_strlen in PyZlib_decompress.
Using Py_ssize_t instead of int solved this for me (on 64bit Linux).

The patch is against
python/trunk/Modules/zlibmodule.c
Revision: 56476

Kind regards,
Peter

--
components: Extension Modules
files: int_overflow.diff
messages: 57047
nosy: PeterW
severity: normal
status: open
title: zlibmodule.c: int overflow in PyZlib_decompress
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file8676/int_overflow.diff

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1372>
__

int_overflow.diff
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1372] zlibmodule.c: int overflow in PyZlib_decompress

[Peter Weseloh]

Peter Weseloh added the comment:

You are right. The format should be 'l'. I overlooked that. In my case the
optional 'buf_size' parameter of 'decompress' is not used anyhow.
Shall I change the patch accordingly?

It work well for me and I now checked the code of PyArg_ParseTuple
(Python/getargs.c) to see what happens. As far as I understand, the given
pointer is casted to a pointer to int if the format is 'i' (line  630) . On
a 64 bit machine this leads to a downcast from a (64 bit) long to a (32 bit)
int, which is OK AFAIK, but I could be wrong.

Thanks for pointing that out,
Peter
2007/11/2, Guido van Rossum <[EMAIL PROTECTED]>:
>
>
> Guido van Rossum added the comment:
>
> I trust that there's a problem, but this can't be right -- the address
> of r_strlen is passed to PyArg_ParseTuple corresponding to an 'i' format
> letter.  That will never do.
>
> --
> assignee:  -> nnorwitz
> nosy: +gvanrossum, nnorwitz
>
> __
> Tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue1372>
> __
>

Added file: http://bugs.python.org/file8681/unnamed

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1372>
__You are right. The format should be 'l'. I overlooked that. In my case 
the optional 'buf_size' parameter of 'decompress' is not used 
anyhow.Shall I change the patch accordingly?It work well for me and 
I now checked the code of PyArg_ParseTuple (Python/getargs.c) to see what 
happens. As far as I understand, the given pointer is casted to a pointer to 
int if the format is 'i' (line  630) . On a 64 bit machine this 
leads to a downcast from a (64 bit) long to a (32 bit) int, which is OK AFAIK, 
but I could be wrong. 
Thanks for pointing that out,Peter2007/11/2, Guido van Rossum <mailto:[EMAIL 
PROTECTED]">[EMAIL PROTECTED]>:
Guido van Rossum added the comment:I trust that there's a 
problem, but this can't be right -- the addressof r_strlen is passed to 
PyArg_ParseTuple corresponding to an 'i' 
formatletter.  That will never do.
--assignee:  -> nnorwitznosy: +gvanrossum, 
nnorwitz__Tracker <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]><http://bugs.python.org/issue1372";>
http://bugs.python.org/issue1372>__

___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1727780] 64/32-bit issue when unpickling random.Random

[Peter Maxwell]

Peter Maxwell added the comment:

For the record, and to prevent dilution of the count of times this bug has 
been encountered: this issue is a duplicate of issue1472695, which was 
later marked "won't fix" for no apparent reason. sligocki's patch is more 
thorough than mine was and I hope it has a better fate too.

--
nosy: +pm67nz

_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1727780>
_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1475] test_popen fails when the directory contains a space

[Peter Åstrand]

Peter Åstrand added the comment:

I think there's some confusion in this bug. The report on
http://pastebin.com/fa947767 indicates a problem in test_popen. This is
a test for os.popen() and it does not have anything to do with the
subprocess module. I believe it is test_popen.py that should be fixed. 

In general, quoting in Windows is very difficult. The documentation
quoted in msg57701 might be correct for some modern version of Windows,
but not for, say, command.com on an older Windows version. I believe the
subprocess is fairly complete when it comes to quoting etc, so changes
should be avoided if possible. 

Since this bug is not about the subprocess module, I've re-assigned to
nobody, hope this is OK.

--
assignee: astrand -> 

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1475>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1475] test_popen fails when the directory contains a space

[Peter Åstrand]

Peter Åstrand added the comment:

>In Python 3.x os.popen is implemented based on subprocess. 

Oh, I see. 

>I believe it's still a problem with subprocess. 

I'm still not convinced of this. Isn't it better to do the quoting
outside subprocess; to let the caller do it? You say that "section 2" is 
our case, but how can we be sure of this: If subprocess is called with
args='"c:\program files\internet explorer\iexplore.exe"', then we have
case 1, right, and surrounding args with another pair of quotes would
mean failure, right?

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1475>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1509] Documentation lacking for the sqlite3 module.

[Peter Mawhorter]

New submission from Peter Mawhorter:

The current documentation for the sqlite3 module on the web fails to 
make any mention of the fetch* functions posessed by the Cursor class 
of that module. It in fact gives no indication of how one should 
extract results from sql queries. The docstrings in the module (viewed 
using the help() function) are woefully incomplete, and are 
inconsistent with the function names:

 |  fetchall(...)
 |  Fetches one row from the resultset.
 |  
 |  fetchmany(...)
 |  Fetches all rows from the resultset.
 |  
 |  fetchone(...)
 |  Fetches several rows from the resultset.
 |  

Both of these things need to be fixed in order for this module to be 
useful for someone who doesn't already know how to use it.

--
components: Extension Modules
messages: 57900
nosy: pmawhorter
severity: minor
status: open
title: Documentation lacking for the sqlite3 module.
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1509>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1509] Documentation lacking for the sqlite3 module.

[Peter Mawhorter]

Peter Mawhorter added the comment:

I could try, but I honestly don't know exactly how the fetch*
functions work. It would probably take me a good couple of hours of
reading before I could write decent documentation, and as much as that
would be great, I'm not about to squeeze that into my college
schedule. I don't actually have a 2.5 checkout, but I thought that at
one point those methods were documented. Is there a way to check the
history of the online documentation and revert those pages?

-Peter Mawhorter

On 11/28/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
>
> Christian Heimes added the comment:
>
> Are you able to provide a patch? Please use a snapshot or svn checkout
> of 2.5 for the patch. We have a new documentation system.
>
> --
> nosy: +tiran
>
> __
> Tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue1509>
> __
>

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1509>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1509] Documentation lacking for the sqlite3 module.

[Peter Mawhorter]

Peter Mawhorter added the comment:

Yes actually... the fetch documentation there is a sufficient
explanation of the functions provided. If it could be added to
docs.python.org, that would be great.

There still remains the fact that the docstrings in the sqlite3 module
don't agree with their function names, but that's a very minor issue,
and wouldn't normally impact usability of the module.

-Peter Mawhorter

On 11/28/07, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
> > I thought that at one point those methods were documented
>
> sqlite3 implements the DB-API:
> http://www.python.org/dev/peps/pep-0249/
> is it the documentation you had in mind?
>
> --
> nosy: +amaury.forgeotdarc
>
> __
> Tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue1509>
> __
>

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1509>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13236] unittest needs more flush calls

[Peter Eisentraut]

New submission from Peter Eisentraut :

I'm using the TextTestRunner class in unittest/runner.py with a special 
file-like object passed in as stream.  Doing this loses some output, because 
the run() method (and some lower-level methods) don't always call flush() on 
the stream.  There is also no obvious cleanup method in the runner class that 
might do this, so I assume run() should do that itself.

Right now, it looks like it assumes that either the stream is effectively 
unbuffered, like stderr, or that the end of the program might flush things, but 
that doesn't always apply.

It looks like the best fix would be a self.stream.flush() call at the end of 
run().  Another flush() call at the end of printErrorList() would also help.

(In the meantime, I have fixed up my special file-like class to flush its 
internal buffers when a newline is seen, which kind of works, but a proper 
cleanup of this matter would still be nice.)

--
components: Library (Lib)
messages: 146043
nosy: petere
priority: normal
severity: normal
status: open
title: unittest needs more flush calls
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

___
Python tracker 
<http://bugs.python.org/issue13236>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13236] unittest needs more flush calls

[Peter Eisentraut]

Peter Eisentraut  added the comment:

Attached is a test file.  The key here is that I'm running the unittest suite 
inside of a long-running server process, so there is no predictable point of 
exit and cleanup.  Therefore, the steps I show at the end of the file should be 
run in an interactive interpreter.  Here is what I see:

>>> import unittest 
>>> 
>>> import testcase 
>>> 
>>> unittest.main(module=testcase)
.F.
==
FAIL: test_three (testcase.test)
--
Traceback (most recent call last):
  File "testcase.py", line 35, in test_three
self.fail("intentional failure")
AssertionError: intentional failure

--
Ran 3 tests in 0.002s

FAILED (failures=1)

That's good.

But:

>>> import unittest 
>>> 
>>> import testcase 
>>> 
>>> unittest.main(module=testcase, testRunner=testcase.FunnyTestRunner, 
>>> exit=False) 
.
F
.


You see, the test report at the end is missing.

I'm happy to consider other ways of addressing this, if anyone has an idea.

--
Added file: http://bugs.python.org/file23527/testcase.py

___
Python tracker 
<http://bugs.python.org/issue13236>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4147] xml.dom.minidom toprettyxml: omit whitespace for text-only elements

[Peter Funk]

Changes by Peter Funk :


--
nosy: +pefu

___
Python tracker 
<http://bugs.python.org/issue4147>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13510] Clarify that readlines() is not needed to iterate over a file

[Peter Otten]

New submission from Peter Otten <__pete...@web.de>:

I've been looking at code on the tutor mailing list for some time, and

for line in file.readlines(): ...

is a common idiom there. I suppose this is because the readlines() method is 
easily discoverable while the proper way (iterate over the file object 
directly) is not.

A note added to the readlines() documentation might help:

"""
You don't need the readlines() method to loop over the lines of a file.
for line in file: process(line)
consumes less memory and is often faster.
"""

--
assignee: docs@python
components: Documentation
messages: 148679
nosy: docs@python, potten
priority: normal
severity: normal
status: open
title: Clarify that readlines() is not needed to iterate over a file
type: feature request

___
Python tracker 
<http://bugs.python.org/issue13510>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13545] Pydoc3.2: TypeError: unorderable types

[Peter Frauenglass]

New submission from Peter Frauenglass :

While attempting to use pydoc, I came across the following error. On my system 
it's simple to reproduce: pydoc -p 1234, then visit http://localhost:1234/ in a 
browser.

A open('/home/(me)/DEBUG', 'w').write(binary)
 right before the m.groups() call created the attached file. Hopefully this is 
enough to help. Thanks.

~$ pydoc3.2 -p 1234 py/core.py 
Server ready at http://localhost:1234/
Server commands: [b]rowser, [q]uit
server> 
Exception happened during processing of request from ('127.0.0.1', 49185)
Traceback (most recent call last):
  File "/usr/lib/python3.2/socketserver.py", line 284, in 
_handle_request_noblock
self.process_request(request, client_address)
  File "/usr/lib/python3.2/socketserver.py", line 310, in process_request
self.finish_request(request, client_address)
  File "/usr/lib/python3.2/socketserver.py", line 323, in finish_request
self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python3.2/socketserver.py", line 638, in __init__
self.handle()
  File "/usr/lib/python3.2/http/server.py", line 399, in handle
self.handle_one_request()
  File "/usr/lib/python3.2/http/server.py", line 387, in handle_one_request
method()
  File "/usr/lib/python3.2/pydoc.py", line 2405, in do_GET
self.path, content_type).encode('utf-8'))
  File "/usr/lib/python3.2/pydoc.py", line 2723, in _url_handler
return get_html_page(url)
  File "/usr/lib/python3.2/pydoc.py", line 2713, in get_html_page
return html.page(title, content)
  File "/usr/lib/python3.2/pydoc.py", line 2497, in page
''' % (title, css_link, html_navbar(), contents)
  File "/usr/lib/python3.2/pydoc.py", line 2530, in html_navbar
""" % (version, html.escape(platform.platform(terse=True)))
  File "/usr/lib/python3.2/platform.py", line 1568, in platform
libcname,libcversion = libc_ver(sys.executable)
  File "/usr/lib/python3.2/platform.py", line 184, in libc_ver
if soversion > version:
TypeError: unorderable types: NoneType() > str()


--
components: Library (Lib)
files: DEBUG
messages: 148951
nosy: threewestwinds
priority: normal
severity: normal
status: open
title: Pydoc3.2: TypeError: unorderable types
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file23861/DEBUG

___
Python tracker 
<http://bugs.python.org/issue13545>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13545] Pydoc3.2: TypeError: unorderable types

[Peter Frauenglass]

Peter Frauenglass  added the comment:

I should also mention that pydoc2.7 -p 1234 works without issue. It seems to be 
a regression.

Also adding lemburg to the Nosy list as the comments on platform.py suggest.

--
nosy: +lemburg

___
Python tracker 
<http://bugs.python.org/issue13545>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13545] Pydoc3.2: TypeError: unorderable types

[Peter Frauenglass]

Peter Frauenglass  added the comment:

The patch in msg<148968> solves the issue for me.

I'm running Linux, originally installed as Mint 9, though upgraded and modified 
incrementally until it's now kubuntu 11.10. I have the "libc6" package version 
"2.13-20ubuntu5" installed.

--

___
Python tracker 
<http://bugs.python.org/issue13545>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11990] redirected output - stdout writes newline as \n in windows

[Peter Csapo]

Peter Csapo  added the comment:

I have having the same issues as Jimbofbx. This seems to stem from changes due 
to issue 10841. All stdio is now opened in binary mode, in consideration that 
it is the TextIOWrapper's job to do endline translation.

The problem here is that the newline mode = '\n' for the TextIOWrapper created 
for stdout. ( see pythonrun.c: create_stdio() ). For windows, the newline mode 
for stdin is already set to null enabling universal newline translation on 
input, and it should be set to null for newline transation on output as well.

OLD CODE
newline = "\n";
#ifdef MS_WINDOWS
if (!write_mode) {
/* translate \r\n to \n for sys.stdin on Windows */
newline = NULL;
}
#endif


FIXED??? CODE
newline = "\n";
#ifdef MS_WINDOWS
/* translate \r\n to \n for sys.stdin on Windows */
/* translate \n to \r\n for sys.stdout on Windows */
newline = NULL;
#endif

--
nosy: +astrobuf

___
Python tracker 
<http://bugs.python.org/issue11990>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Peter Wentworth]

Peter Wentworth  added the comment:

I can confirm the crash persists as of Python 3.1.3 on Windows, and would like 
to add my vote to prioritizing it.  

Without having delved into the code, it seems strange that the rapid stream of 
events is causing stack overflow / recursion limit problems.

It suggests that tkinter is allowing new event arrivals to interrupt older 
event handling, so that the older ones remain incomplete as the newer ones pile 
up on the stack. If this is the case, it is going to lead to long-term 
instability, and needs attention.

The usual technique is to use a queue to decouple "occurs now" from "handle 
immediately". (The OS puts the mouse and keyboard events onto window's event 
queue).  So the mainloop that services the event queue should not start 
handling a new queued event until the previous handling has completed.

--
nosy: +Peter.Wentworth

___
Python tracker 
<http://bugs.python.org/issue6717>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Peter Wentworth]

Peter Wentworth  added the comment:

Attached is a crashing program that shows that the event handler is called 
again before activation of the prior instance has completed.

I also have a second turtle that queues the nested events.  It doesn't crash 
the system, at least.

Perhaps someone can also explain why the handler doesn't work if I leave out 
the global declaration.

--
Added file: http://bugs.python.org/file22072/drag_bug_is_nesting_events.py

___
Python tracker 
<http://bugs.python.org/issue6717>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Peter Wentworth]

Changes by Peter Wentworth :


Removed file: http://bugs.python.org/file22072/drag_bug_is_nesting_events.py

___
Python tracker 
<http://bugs.python.org/issue6717>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6717] Some problem with recursion handling

[Peter Wentworth]

Peter Wentworth  added the comment:

Oops, I wish I hadn't asked that silly question about the global declaration!

Here is the tweaked file...

--
Added file: http://bugs.python.org/file22073/drag_bug_is_nesting_events.py

___
Python tracker 
<http://bugs.python.org/issue6717>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12159] Integer Overflow in __len__

[Peter Fankhaenel]

New submission from Peter Fankhaenel :

An OverflowError is emitted in case the return value of __len__
exceeds 2**31-1.

The following code:

class C (object):
def __len__ (self):
   return self.l

c = C()
c.l = 2**31

len (c)

# leads to an OverflowError in the last line. It works flawless for

c.__len__ ()

--
components: Windows
messages: 136644
nosy: peter.fankhaenel
priority: normal
severity: normal
status: open
title: Integer Overflow in __len__
versions: Python 2.6, Python 2.7

___
Python tracker 
<http://bugs.python.org/issue12159>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11889] 'enumerate' 'start' parameter documentation is confusing

[Peter Hammer]

Peter Hammer  added the comment:

"""
Changing the 'enumerate' doc string text from:

|  (0, seq[0]), (1, seq[1]), (2, seq[2]), ...

to:

|  (start, seq[0]), (start+1, seq[1]), (start+2, seq[2]), ...

would completely disambiguate the doc string at the modest cost of
sixteen additional characters, a small price for pellucid clarity.

The proposed changes to the formal documentation also seem to me to
be prudent, and I hope at this late writing, they have already been
committed.

I conclude with a code fragment for the edification of R. David Murray.
"""


class numerate(object):
  """
  A demonstration of a plausible incorrect interpretation of
  the 'enumerate' function's doc string and documentation.
  """
  def __init__(self,seq,start=0):
self.seq=seq; self.index=start-1
try:
  if seq.next: pass #test for iterable
  for i in xrange(start): self.seq.next()
except:
  if type(seq)==dict: self.seq=seq.keys()
  self.seq=iter(self.seq[start:])

  def next(self):
self.index+=1
return self.index,self.seq.next()


  def __iter__(self): return self


if __name__ == "__main__":
  #s=['spring','summer','autumn','winter']
  s={'spring':'a','summer':'b','autumn':'c','winter':'d'}
  #s=enumerate(s)#,2)
  s=numerate(s,2)
  for t in s: print t

--

___
Python tracker 
<http://bugs.python.org/issue11889>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1711800] SequenceMatcher bug with insert/delete block after "replace"

[Peter Waller]

Peter Waller  added the comment:

Apologies for the bump, but it has been more than a year and I did attach a 
patch! :-)

What next?

--

___
Python tracker 
<http://bugs.python.org/issue1711800>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8668] Packaging: add a 'develop' command

[Peter Waller]

Changes by Peter Waller :


--
nosy: +Peter.Waller

___
Python tracker 
<http://bugs.python.org/issue8668>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8668] Packaging: add a 'develop' command

[Peter Waller]

Peter Waller  added the comment:

Hi - Great to see this functionality coming. There is one feature of it that I 
would really like to see fixed, which is currently broken in 
setuptools/distribute - I'm sorry if this is the wrong forum for this note, but 
I wanted to add it to the discussion somewhere.

That feature is the "package_dir" argument to setup(). If the sources aren't in 
the root directory, the package doesn't function correctly with `python 
setup.py develop`

Here is a reference to an issue filed against distribute:

https://bitbucket.org/tarek/distribute/issue/177/setuppy-develop-doesnt-support-package_dir-arg-to

Is there any possibility of seeing this work correctly? A lot of packages use 
it, and for them, `develop` is currently broken.

Apologies if this feature is implemented and I missed it, but I see no 
reference to "package_dir" in the patch, so I would be (pleasantly) surprised 
if it was implemented. I would be happy to provide a testcase on request.

--

___
Python tracker 
<http://bugs.python.org/issue8668>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12444] accept sets or collections for str.strip/lstrip/rstrip

[Peter Eisentraut]

New submission from Peter Eisentraut :

It appears to be a pretty common mistake to think that the argument of 
str.strip/lstrip/rstrip is a substring rather than a set of characters.  To 
allow a more clearer notation, it would be nice if these functions also 
accepted an argument other than a string, for example a set or any collection.  
Then you could write, for example:

a.strip({'a', 'b', 'c'})

I suggest to either add support for sets specifically, or more generally 
anything that supports the "in" operator.

I can try to code it up if it sounds acceptable.

--
components: Library (Lib)
messages: 139449
nosy: petere
priority: normal
severity: normal
status: open
title: accept sets or collections for str.strip/lstrip/rstrip
type: feature request

___
Python tracker 
<http://bugs.python.org/issue12444>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12457] type() returns incorrect type for nested classes

[Peter Williams]

New submission from Peter Williams :

The built in type() function returns incorrect type names for nested classes 
which in turn causes pickle to crash when used with nested classes as it cannot 
find the nested class definitions from the using the string returned by type().

e.g. if I have an instance "inner" of class Inner which is defined inside 
(nested in) the class Outer:

type(inner) returns  instead of 

The isinstance() function, as expected, returns True for isinstance(inner, 
Outer.Inner) and raises a NameError exception for isinstance(inner, Inner).

However, isinstance(inner, type(inner)) returns True which indicates the core 
functionality is OK and this conforms to the fact that no problems were 
encountered until I tried to pickle an object containing nested classes.

My system is Fedora 15 x86_64 and Python versions are 2.7.1 and 3.2.

A short program illustrating the problem is attached.

--
components: None
files: nested_class_bug.py
messages: 139542
nosy: pwil3058
priority: normal
severity: normal
status: open
title: type() returns incorrect type for nested classes
type: crash
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file22531/nested_class_bug.py

___
Python tracker 
<http://bugs.python.org/issue12457>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12457] type() returns incorrect type for nested classes

[Peter Williams]

Peter Williams  added the comment:

The class I was pickling was a top level class but a field inside that class 
had an instance of a nested class set as its value.  The error message produced 
indicated that the reason for failure was the inability of pickle to find the 
class definition and (I think) that was caused by the problem with type()'s 
returned value.

Perhaps fixing the problem with type() would allow the restriction on pickling 
nested classes to be removed?  Was that restriction a deliberate design 
decision (illogical) or the result of not being able to get it to work?

Re whether the behaviour of type() is a problem:  I believe it is as, in 
addition to the inconsistencies between type() and isinstance() that I 
described in my original report, there is the confusion that arises if two 
separate classes have nested classes with the same name (see mini program 
confusion.py as an example).  This seems to compromise the whole purpose of 
namespaces and is inconsistent with the way modules are treated in determining 
the name reported by type().

--
type: behavior -> crash
Added file: http://bugs.python.org/file22544/confusion.py

___
Python tracker 
<http://bugs.python.org/issue12457>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12487] urllib2.urlopen() returns object missing context manager

[Peter Schuller]

New submission from Peter Schuller :

The documentation states it returns a "file-like object". In Python 2.5+ I 
expect such file-like objects to have a context manager for use with the with 
statement.

In my particular use-case, the lack comes from urllib.addinfourl but I have not 
investigated what the possible types returned may be.

--
components: Library (Lib)
messages: 139746
nosy: scode
priority: normal
severity: normal
status: open
title: urllib2.urlopen() returns object missing context manager
type: behavior
versions: Python 2.6

___
Python tracker 
<http://bugs.python.org/issue12487>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12531] documentation index entries for * and **

[Peter Eisentraut]

New submission from Peter Eisentraut :

The existing documentation index entries for * and ** only point to their use 
in function definitions but not to their use in function calls.  I was looking 
for the latter, and it was difficult to find without this.  Here is a small 
patch to add the additional entries.

--
assignee: docs@python
components: Documentation
files: python-doc-index-**.patch
keywords: patch
messages: 140113
nosy: docs@python, petere
priority: normal
severity: normal
status: open
title: documentation index entries for * and **
versions: Python 3.3
Added file: http://bugs.python.org/file22619/python-doc-index-**.patch

___
Python tracker 
<http://bugs.python.org/issue12531>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12540] "Restart Shell" command leaves pythonw.exe processes running

[Peter Caven]

New submission from Peter Caven :

On Windows Vista (x64) the IDLE "Restart Shell" command leaves a "pythonw.exe" 
process running each time that the command is used.
Observed in Python 3.2.1 release and RC2.

--
components: IDLE
messages: 140179
nosy: Peter.Caven
priority: normal
severity: normal
status: open
title: "Restart Shell" command leaves pythonw.exe processes running
type: resource usage
versions: Python 3.2

___
Python tracker 
<http://bugs.python.org/issue12540>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12480] urllib2 doesn't use proxy (fieddler2), configed the proxy with ProxyHandler

[Peter Bumbulis]

Peter Bumbulis  added the comment:

proxy_bypass_registry in urllib.py does not handle the ProxyOverride registry 
value properly:  it treats an empty override as *, i.e. bypass the proxy for 
all hosts.  This behavior does not match other programs (e.g. Chrome) and can 
be easily obtained by specify * for the override.  One fix would be to ignore 
empty tests, for example:


for test in proxyOverride:
if test:
if test == '':
...
return 0


Perhaps whitespace should be stripped as well.

The problem arises because fiddler2 leaves a trailing ; on the ProxyOverride 
string.

One possible workaround is to set
urllib.proxy_bypass = lambda h: 0
to disable bypass checking.  Another alternative would be to specify the proxy 
settings in the http_proxy environment variable (proxy_bypass_registry is not 
called in this case).

--
nosy: +pbumbulis

___
Python tracker 
<http://bugs.python.org/issue12480>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12540] "Restart Shell" command leaves pythonw.exe processes running

[Peter Caven]

Peter Caven  added the comment:

Terry,  sorry about the delay in responding: I'm using 32bit Python. I haven't 
had a chance yet to try the 64 bit release.

--

___
Python tracker 
<http://bugs.python.org/issue12540>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com