[issue16878] argparse: positional args with nargs='*' defaults to []

[paul j3]

paul j3 added the comment:

In this example:

>>> p.add_argument('--foo', nargs='*', default=None)
>>> p.parse_args([])
Namespace(foo=None)
>>> p.parse_args(['--foo'])
Namespace(foo=[])

'p.parse_args([])' just assigns the default to 'foo' in the Namespace.

"p.parse_args(['--foo'])" invokes 'take_action(,[]).  That is, it 
'assigns' an empty array to 'foo'.   The same thing would happen if 'foo' was a 
positional.  

'take_action' then passes these arguments to '_get_values'.  That is where the 
differences between '?' and '*' arise.

The key pieces of code in '_get_values' when arg_strings==[] are:

# optional argument produces a default when not present
if not arg_strings and action.nargs == OPTIONAL:
value = action.default
# and evaluate 'value' if is a string

# when nargs='*' on a positional, if there were no command-line
# args, use the default if it is anything other than None
elif (not arg_strings and action.nargs == ZERO_OR_MORE ...):
if action.default is not None:
value = action.default
else:
value = arg_strings # i.e. []

In other words, if nargs='?', the attribute gets its default value.  But for 
'*', this is true only if the default is not None.

So in:

parse([], nargs='?')# get the default value: None
parse([], nargs='*')# default is None, get arg_strings []
parse([], nargs='*', default=None)  # same case
parse([], nargs='*', default=False) # default is not None, get default
parse([], nargs='*', default=0) # same case

I tried changing the _get_values() so '*' got the default (like '?' does), and 
got 54 failures when running test_argparse.py.

--
nosy: +paul.j3

___
Python tracker 

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

[issue17532] IDLE: Always include "Options" menu on MacOSX

[Guilherme Simões]

Guilherme Simões added the comment:

I actually removed something I shouldn't have in the first patch so I'm 
attaching a new one.

--
Added file: http://bugs.python.org/file29899/17532MenuOptions-1.patch

___
Python tracker 

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

[issue16694] Add pure Python operator module

[Antoine Pitrou]

Antoine Pitrou added the comment:

length_hint() looks ok as well.

--

___
Python tracker 

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

[issue17758] test_site fails when the user does not have a home directory

[Antoine Pitrou]

Antoine Pitrou added the comment:

As a sidenote, I find it a bit scary that test_site even *tries* to create 
USER_SITE. The test suite shouldn't touch anything outside of test-specific 
temp files.

--
nosy: +christian.heimes, pitrou
type: enhancement -> behavior
versions: +Python 2.7

___
Python tracker 

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

[issue17758] test_site fails when the user does not have a home directory

[Christian Heimes]

Christian Heimes added the comment:

Don't be scared ... :)

I'll think about a solution.

--
assignee:  -> christian.heimes

___
Python tracker 

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

[issue17772] test_gdb doesn't detect a gdb built with python3.3 (or higher)

[Matthias Klose]

New submission from Matthias Klose:

test_gdb skipped -- gdb not built with embedded python support

$ gdb --version
GNU gdb (GDB) 7.5.91.20130408
$ ldd /usr/bin/gdb|grep python
libpython3.3m.so.1.0 => /usr/lib/libpython3.3m.so.1.0

--
messages: 187151
nosy: dmalcolm, doko
priority: normal
severity: normal
stage: needs patch
status: open
title: test_gdb doesn't detect a gdb built with python3.3 (or higher)
versions: Python 3.3, Python 3.4

___
Python tracker 

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

[issue17773] test_pydoc fails with the installed testsuite (2.7)

[Matthias Klose]

New submission from Matthias Klose:

these are failures not seen with 3.x, running with -S doesn't help.

test_pydoc
test test_pydoc failed -- multiple errors occurred; run in verbose mode for 
details
1 test failed:
test_pydoc
Re-running failed tests in verbose mode
Re-running test 'test_pydoc' in verbose mode
test_html_doc (test.test_pydoc.PyDocDocTest) ... 
--- expected
+++ got
@@ -19 +19 @@
-B
+B
@@ -22 +22 @@
-A
+A
@@ -56,12 +55,0 @@
-
- 
-Functions
-
-   
-doc_func()This function solves all of the world's problems:
-hunger
-lack of Python
-war
- nodoc_func()
-
-

FAIL
test_input_strip (test.test_pydoc.PyDocDocTest) ... ok
test_issue8225 (test.test_pydoc.PyDocDocTest) ... ok
test_non_str_name (test.test_pydoc.PyDocDocTest) ... ok
test_not_here (test.test_pydoc.PyDocDocTest) ... ok
test_stripid (test.test_pydoc.PyDocDocTest) ... ok
test_text_doc (test.test_pydoc.PyDocDocTest) ... 
--- expected
+++ got
@@ -34,9 +33,0 @@
-FUNCTIONS
-doc_func()
-This function solves all of the world's problems:
-hunger
-lack of Python
-war
-
-nodoc_func()
-

FAIL
test_apropos_with_bad_package (test.test_pydoc.PydocImportTest) ... FAIL
test_apropos_with_unreadable_dir (test.test_pydoc.PydocImportTest) ... FAIL
test_badimport (test.test_pydoc.PydocImportTest) ... ok
test_class (test.test_pydoc.TestDescriptions) ... ok
test_classic_class (test.test_pydoc.TestDescriptions) ... ok
test_module (test.test_pydoc.TestDescriptions) ... ok
test_namedtuple_public_underscore (test.test_pydoc.TestDescriptions) ... ERROR
test_builtin (test.test_pydoc.TestHelper) ... ok
test_keywords (test.test_pydoc.TestHelper) ... test test_pydoc failed -- 
multiple errors occurred
ok

==
ERROR: test_namedtuple_public_underscore (test.test_pydoc.TestDescriptions)
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/test/test_pydoc.py", line 383, in 
test_namedtuple_public_underscore
help(NT)
NameError: global name 'help' is not defined

==
FAIL: test_html_doc (test.test_pydoc.PyDocDocTest)
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/test/test_pydoc.py", line 248, in test_html_doc
self.fail("outputs are not equal, see diff above")
AssertionError: outputs are not equal, see diff above

==
FAIL: test_text_doc (test.test_pydoc.PyDocDocTest)
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/test/test_pydoc.py", line 259, in test_text_doc
self.fail("outputs are not equal, see diff above")
AssertionError: outputs are not equal, see diff above

==
FAIL: test_apropos_with_bad_package (test.test_pydoc.PydocImportTest)
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/test/test_pydoc.py", line 341, in 
test_apropos_with_bad_package
result = run_pydoc('zqwykjv', '-k', PYTHONPATH=TESTFN)
  File "/usr/lib/python2.7/test/test_pydoc.py", line 196, in run_pydoc
rc, out, err = assert_python_ok('-B', pydoc.__file__, *args, **env)
  File "/usr/lib/python2.7/test/script_helper.py", line 55, in assert_python_ok
return _assert_python(True, *args, **env_vars)
  File "/usr/lib/python2.7/test/script_helper.py", line 47, in _assert_python
"stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is -11, stderr follows:


==
FAIL: test_apropos_with_unreadable_dir (test.test_pydoc.PydocImportTest)
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/test/test_pydoc.py", line 351, in 
test_apropos_with_unreadable_dir
result = run_pydoc('zqwykjv', '-k', PYTHONPATH=TESTFN)
  File "/usr/lib/python2.7/test/test_pydoc.py", line 196, in run_pydoc
rc, out, err = assert_python_ok('-B', pydoc.__file__, *args, **env)
  File "/usr/lib/python2.7/test/script_helper.py", line 55, in assert_python_ok
return _assert_python(True, *args, **env_vars)
  File "/usr/lib/python2.7/test/script_helper.py", line 47, in _assert_python
"stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is -11, stderr follows:


--
Ran 16 tests in 3.323s

FAILED (failures=4, errors=1)
[47527 refs]

--
components: Tests
messages: 187152
nosy: doko
priority: normal
severity: normal
stage: needs patch
status: open
title: test_pydoc 

[issue17750] allow the testsuite to run in the installed location

[Matthias Klose]

Changes by Matthias Klose :


--
dependencies: +test_pydoc fails with the installed testsuite (2.7)

___
Python tracker 

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

[issue17353] Plistlib outputs empty data tags when deeply nested

[Ronald Oussoren]

Ronald Oussoren added the comment:

The tests look good, thanks for writing them.

--

___
Python tracker 

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

[issue17707] Multiprocessing queue get method does not block for short timeouts

[Roundup Robot]

Roundup Robot added the comment:

New changeset 65623d7dc76e by Giampaolo Rodola' in branch '3.3':
Fix issue #17707: multiprocessing.Queue's get() method does not block for short 
timeouts.
http://hg.python.org/cpython/rev/65623d7dc76e

--
nosy: +python-dev

___
Python tracker 

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

[issue17707] Multiprocessing queue get method does not block for short timeouts

[Roundup Robot]

Roundup Robot added the comment:

New changeset 87882c96d138 by Giampaolo Rodola' in branch 'default':
Fix issue #17707: multiprocessing.Queue's get() method does not block for short 
timeouts.
http://hg.python.org/cpython/rev/87882c96d138

--

___
Python tracker 

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

[issue17707] Multiprocessing queue get method does not block for short timeouts

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
keywords: +3.2regression, 3.3regression
resolution:  -> fixed
status: open -> closed
versions:  -Python 3.2

___
Python tracker 

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

[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

[Tim Golden]

Tim Golden added the comment:

Attached is a q&d script to produce the list of extension -> mimetype maps for 
a version of the mimetypes module.

--
Added file: http://bugs.python.org/file29900/mt.py

___
Python tracker 

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

[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

[Tim Golden]

Tim Golden added the comment:

Three outputs produced by mt.py: tip as-is; tip without registry; tip
with new approach to registry. The results for 2.7 are near-enough
identical. Likewise the results for an elevated prompt.

--
Added file: http://bugs.python.org/file29901/mt-tip.txt
Added file: http://bugs.python.org/file29902/mt-tip-newregistry.txt
Added file: http://bugs.python.org/file29903/mt-tip-noregistry.txt

___
Python tracker 

___.jpg => image/jpg
.mid => audio/midi
.midi => audio/midi
.pct => image/pict
.pic => image/pict
.pict => image/pict
.rtf => application/rtf
.xul => text/xul
.3g2 => video/3gpp2
.3gp => video/3gpp
.AMR => audio/AMR
.a => application/octet-stream
.aac => audio/x-aac
.ac3 => audio/x-ac3
.acrobatsecuritysettings => application/vnd.adobe.acrobat-security-settings
.adts => audio/vnd.dlna.adts
.ai => application/postscript
.aif => audio/x-aiff
.aifc => audio/x-aiff
.aiff => audio/x-aiff
.amc => application/x-mpeg
.application => application/x-ms-application
.asx => video/x-ms-asf-plugin
.au => audio/basic
.avi => video/x-msvideo
.bat => text/plain
.bcpio => application/x-bcpio
.bin => application/octet-stream
.bmp => image/bmp
.c => text/plain
.c2r => text/vnd-ms.click2record+xml
.caf => audio/x-caf
.cat => vnd.ms-pki.seccat
.cdf => application/x-netcdf
.cer => x-x509-ca-cert
.contact => text/x-ms-contact
.cpio => application/x-cpio
.crl => pkix-crl
.csh => application/x-csh
.css => text/css
.dir => application/x-director
.dll => application/octet-stream
.doc => application/msword
.dot => application/msword
.dvi => application/x-dvi
.dwfx => model/vnd.dwfx+xps
.easmx => model/vnd.easmx+xps
.edrwx => model/vnd.edrwx+xps
.eml => message/rfc822
.eprtx => model/vnd.eprtx+xps
.eps => application/postscript
.etx => text/x-setext
.exe => application/octet-stream
.fdf => application/vnd.fdf
.fif => application/fractals
.flc => video/flc
.gif => image/gif
.gsm => audio/x-gsm
.gtar => application/x-gtar
.gz => application/x-gzip
.h => text/plain
.hdf => application/x-hdf
.hqx => application/mac-binhex40
.hta => application/hta
.htc => text/x-component
.htm => text/html
.html => text/html
.ico => image/x-icon
.ics => text/calendar
.ief => image/ief
.iqy => text/x-ms-iqy
.jnlp => application/x-java-jnlp-file
.jp2 => image/x-jpeg2000-image
.jpe => image/jpeg
.jpeg => image/jpeg
.jpg => image/pjpeg
.js => application/javascript
.jtx => application/x-jtx+xps
.ksh => text/plain
.latex => application/x-latex
.m1v => video/mpeg
.m3u => audio/x-mpegurl
.m3u8 => application/vnd.apple.mpegurl
.m4a => audio/x-m4a
.m4b => audio/x-m4b
.m4p => audio/x-m4p
.m4v => video/x-m4v
.man => application/x-troff-man
.mdi => image/vnd.ms-modi
.me => application/x-troff-me
.mht => message/rfc822
.mhtml => message/rfc822
.mid => midi/mid
.mif => application/x-mif
.mov => video/quicktime
.movie => video/x-sgi-movie
.mp2 => audio/mpeg
.mp3 => audio/x-mpg
.mp4 => video/mp4
.mpa => video/mpeg
.mpe => video/mpeg
.mpeg => video/x-mpeg2a
.mpf => application/vnd.ms-mediapackage
.mpg => video/mpeg
.ms => application/x-troff-ms
.nc => application/x-netcdf
.nix => application/x-mix-transfer
.nws => message/rfc822
.o => application/octet-stream
.obj => application/octet-stream
.oda => application/oda
.odc => text/x-ms-odc
.osdx => application/opensearchdescription+xml
.p10 => pkcs10
.p12 => x-pkcs12
.p7b => x-pkcs7-certificates
.p7c => application/pkcs7-mime
.p7m => pkcs7-mime
.p7r => x-pkcs7-certreqresp
.p7s => pkcs7-signature
.pbm => image/x-portable-bitmap
.pdf => application/pdf
.pdfxml => application/vnd.adobe.pdfxml
.pdx => application/vnd.adobe.pdx
.pfx => application/x-pkcs12
.pgm => image/x-portable-graymap
.pict => image/x-pict
.pko => vnd.ms-pki.pko
.pl => text/plain
.pls => audio/x-scpls
.png => image/x-png
.pnm => image/x-portable-anymap
.pntg => image/x-macpaint
.pot => application/vnd.ms-powerpoint
.ppa => application/vnd.ms-powerpoint
.ppm => image/x-portable-pixmap
.pps => application/vnd.ms-powerpoint
.ppt => application/x-mspowerpoint
.ps => application/postscript
.pwz => application/vnd.ms-powerpoint
.py => text/x-python
.pyc => application/x-python-code
.pyo => application/x-python-code
.qcp => audio/vnd.qcelp
.qt => video/quicktime
.qtif => image/x-quicktime
.qtl => application/x-quicktimeplayer
.ra => audio/x-pn-realaudio
.ram => application/x-pn-realaudio
.ras => image/x-cmu-raster
.rdf => application/xml
.rels => application/vnd.ms-package.relationships+xml
.rgb => image/x-rgb
.roff => application/x-troff
.rqy => text/x-ms-rqy
.rtsp => application/x-rtsp
.rtx => text/richtext
.sdp => application/x-sdp
.sdv => video/sd-video
.sgi => image/x-sgi
.sgm => text/x-sgml
.sgml => text/x-sgml
.sh => application/x-sh
.shar => application/x-shar
.sit => application/x-stuffit
.slupkg-ms => application/x-ms-license
.snd => audio/basic
.so => application/octet-stream
.spl => application/futuresplash
.sr

[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

[Tim Golden]

Tim Golden added the comment:

There seems to be a consensus that the current behaviour is undesirable,
indeed "broken" for any meaningful use. 

The critical argument against the current Registry approach is that it
returns unexpected (or outright incorrect) mimetypes for very standard
extensions.

The arguments against reading the Registry at all are:

* That it requires some extra level of privilege to read the appropriate
keys.

* That there is a startup cost to reading the Registry

* That it can be and is updated by arbitrary programs (typically during
installation) and therefore its values cannot be relied upon.


We have 3.5 proposals on the table:

1) Don't read the registry at all, ie revert issue4969 (this is what Ben
Hoyt is advocating) [noregistry]

2) Read the registry *before* reading the standard types (this is not
strongly advocated by anyone).

3) Read the registry but in a different way, mapping from extension to
mimetype rather than vice versa. (This is Dave Chambers' patch from
issue15207). [newregistry]

3a) Lookup as per (3) but only on demand. This eliminates any startup cost.

I've produced three output files from a simple dump of the mimetypes database. 
For the purposes of taking this  forward, we're really comparing the noregistry 
and the newregistry variants.

One key issue is what to do when the same key occurs in both sets but with a 
different value. (Examples include .avi -> video/x-msvideo vs video/avi; and 
.zip -> application/zip vs application/x-zip-compressed).

And the other key issue is whether the overheads (security, speed) of using the 
registry outweigh its usefulness in any case.

Could I ask those who would remove the registry use altogether to comment on 
the newregistry output (generating your own if it helps) to see whether it 
changes your views at all.

Either approach -- no-registry or new-registry -- feasible and the code churn 
is about equal. I'm unsure about compatibility issues: it's hard to see anyone 
relying on the incorrect mimetypes; but it's certainly possible to see someone 
relying on the additional (correct) mimetypes.

--

___
Python tracker 

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

[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

I think it's important to stick to established standards for
MIME types and to make sure that Python returns the same values
on all platforms using the default settings.

Apache comes with a mime.types file which includes both the
official IANA types and many common, but unregistered types:

http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/mime.types?view=markup

This can be used as reference (much like we use the X.org locale
database as reference for the locale module).

If an application wants to use the Windows registry settings instead,
that's fine, but it should not be the default if there's a difference
in output compared to the hard-coded list in mimetypes.

Note that this would probably require a redesign of the
internals of the mimetypes module. It currently provides only a
small subset as default mapping and then reads the full set from
one of the mime.types files it can find on the system.
Such a redesign would only be possible for Python 3.4, not
Python 2.7.

--
nosy: +lemburg

___
Python tracker 

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

[issue17774] unable to disable -r in run_tests.py

[Matthias Klose]

New submission from Matthias Klose:

it is not possible to disable -r in run_tests.py. Other options like -u or -j 
can be overwritten, but not removing -r.

--
components: Tests
messages: 187160
nosy: doko
priority: normal
severity: normal
stage: needs patch
status: open
title: unable to disable -r in run_tests.py
type: behavior
versions: Python 3.3, Python 3.4

___
Python tracker 

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

[issue17724] urllib -- add_handler method refactoring for clarity

[Max Mautner]

Changes by Max Mautner :


--
resolution:  -> invalid
status: open -> closed

___
Python tracker 

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

[issue17775] Error with Hello, World in 3.3.1

[David Walker]

New submission from David Walker:

I'm brand new to Python (and programming in general) and I'm reading "Python 
for Dummies" while trying to learn this.  I downloaded 3.3.1 and when I entered 
the command

>>> print "Hello, World!"

it would give the following error:

SyntaxError: invalid syntax
  File "", line 1
 print "Hello, World!"

Yet when I do the same thing in v 2.7.4 it works fine.  Is there something I'm 
doing wrong?  Thanks in advance

--
components: Windows
messages: 187161
nosy: walkah21
priority: normal
severity: normal
status: open
title: Error with Hello, World in 3.3.1
type: compile error
versions: Python 3.3

___
Python tracker 

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

[issue17618] base85 encoding

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

After a more careful look of the b85encode code I say that it's implementation 
is not optimal. For the sake of simplicity the entire volume of data is copied 
several times. This can affect the processing of a large volume of data. On 
other hand, this dumb copying can be faster then more smart processing in 
a85encode. Only benchmarks will show the truth.

Using a trick with struct.unpack() has very unpleasant side effect. It might be 
a few speed up encoding, but creates the Struct object with the size is many 
times larger than the size of the processed data. Worse, this object is cached 
and continues to consume memory. Since the size of the data most likely will be 
unique, almost every call of b85encode creates a new object. This will lead to 
memory leaks.

--

___
Python tracker 

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

[issue17775] Error with Hello, World in 3.3.1

[Ramchandra Apte]

Ramchandra Apte added the comment:

Python 3 and Python 2 have different syntax (same code won't work with both 
versions).
You would have to run print("Hello, World")
Please close this bug as invalid.

--
nosy: +Ramchandra Apte
type: compile error -> behavior

___
Python tracker 

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

[issue17775] Error with Hello, World in 3.3.1

[David Walker]

Changes by David Walker :


--
resolution:  -> invalid
status: open -> closed

___
Python tracker 

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

[issue17768] _decimal: allow NUL fill character

[Ramchandra Apte]

Ramchandra Apte added the comment:

Yes.

--
nosy: +Ramchandra Apte

___
Python tracker 

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

[issue17776] IDLE Internationalization

[Damien Marié]

New submission from Damien Marié:

Following the issue 17760

Internationalization should be implemented.
I propose to implement it as an optionnal settings first. And with the gettext 
library.

I'm not experienced with the idlelib module but here is a first patch, don't 
hesitate to comment it. It just add i18n to the menu for now.

--
components: IDLE
files: patch.diff
keywords: patch
messages: 187165
nosy: Damien.Marié
priority: normal
severity: normal
status: open
title: IDLE Internationalization
type: enhancement
Added file: http://bugs.python.org/file29904/patch.diff

___
Python tracker 

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

[issue9849] Argparse needs better error handling for nargs

[Mark Lawrence]

Mark Lawrence added the comment:

The first error raised is "TypeError: 'str' object cannot be interpreted as an 
integer", followed by "ValueError: length of metavar tuple does not match 
nargs".  Therefore the code has already been changed to reflect the title of 
this issue.  If other code changes are needed I believe that should be done in 
a new or another already existing issue.

--

___
Python tracker 

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

[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

[Dave Chambers]

Dave Chambers added the comment:

Enough with the bikeshedding... it's been 10 months... fix the bug.

--

___
Python tracker 

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

[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

[Brian Curtin]

Brian Curtin added the comment:

Just an FYI, but if it takes 10 more months to get it right, we'll do that.

--

___
Python tracker 

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

[issue17673] add `copy_from` argument to temporaryfile

[R. David Murray]

R. David Murray added the comment:

Personally I prefer having the test create the needed test file, rather than 
adding a new file to the repository, for small files.  That's just my opinion, 
though; as you found what you did is common practice currently.  Your patch 
doesn't include the file, though.

(I haven't reviewed the rest of the patch.)

--
nosy: +r.david.murray

___
Python tracker 

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

[issue17673] add `copy_from` argument to temporaryfile

[Kyle Roberts]

Kyle Roberts added the comment:

Thanks for the quick response. The test file is sandwiched in between the two 
patch files, so it's easy to miss. You made a great point about not cluttering 
up the repo with any unnecessary files. I'll change the test methods to create 
a new copy_from file that's closed at the end of each test.

--

___
Python tracker 

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

[issue17673] add `copy_from` argument to temporaryfile

[R. David Murray]

R. David Murray added the comment:

I did miss it.  Not that it matters if you are going to rewrite the test, but 
FYI you can include new files in a patch by adding them ('hg add') before doing 
the 'hg diff' to generate the patch.

--

___
Python tracker 

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

[issue17618] base85 encoding

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

After searching a lot of other implementations of this encoding I conclude that 
there are at least three different variants.

1. The original btoa/atob encoding. 4 zeros are packaged as 'z', last 
incomplete 4 bytes are padded by zeros, an output is wrapped into several lines 
and decoder ignores '\n'. There are many implementations of this algorithm in 
different languages.

2. Adobe version. This is an extended version of (1). The last incomplete 4 
bytes produces less then 5 output characters, an output is enclosed in <~ and 
~>. Decoder ignores all ascii whitespaces, not only '\n'. There are many 
implementations of this algorithm in different languages.

3. Git and Mercurial version. This is a very simplified version of (1) with an 
alternative character set. Zeros are not packed, an output is not broken into 
several lines and decoder doesn't ignores any whitespaces. I don't know is 
whether this variant used besides Git and Mercurial.

Some implementations combine (1) and (2) (optionally enclose an output in <~ 
and ~>, optionally wrap an output into several lines, optionally pad last 4 
incomplete bytes).

--

___
Python tracker 

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

[issue17777] Unrecognized string literal escape sequences give SyntaxErrors

[Reynir Reynisson]

New submission from Reynir Reynisson:

Strings like "\u" trigger a SyntaxError. According to the language reference 
"all unrecognized escape sequences are left in the string unchanged"[0]. The 
string "\u" clearly doesn't match any of the escape sequences (in particular 
\u).

This may be intentional, but it is not clear from the language reference that 
this is the case. If it is intentional it should probably be stated more 
explicit in the language reference.

I think this may be confusing for new users since the syntax errors may lead 
them to believe the interpreter will give syntax error for all unrecognized 
escape sequences.

[0]: http://docs.python.org/3/reference/lexical_analysis.html#literals

--
assignee: docs@python
components: Documentation, Unicode
messages: 187173
nosy: docs@python, ezio.melotti, reynir
priority: normal
severity: normal
status: open
title: Unrecognized string literal escape sequences give SyntaxErrors
type: behavior
versions: Python 3.3

___
Python tracker 

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

[issue17618] base85 encoding

[Antoine Pitrou]

Antoine Pitrou added the comment:

> After searching a lot of other implementations of this encoding I
> conclude that there are at least three different variants.

Yes. The current proposal is to include both the Adobe version ("ascii85")
and the Mercurial/Git version ("base85"). btoa/atob seems extinct.

--

___
Python tracker 

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

[issue17777] Unrecognized string literal escape sequences give SyntaxErrors

[R. David Murray]

R. David Murray added the comment:

It is a recognized escape sequence, but the syntax of the escape sequence is 
wrong, thus the syntax error.  An "escape sequence" is a backslash character 
followed by a letter.  Perhaps that is the bit that needs to be clarified in 
the docs?

--
nosy: +r.david.murray

___
Python tracker 

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

[issue17776] IDLE Internationalization

[Olivier Berger]

Olivier Berger added the comment:

Excellent. I've started playing with pygettext and msgfmt and it looks like 
this works, from the initial tests I've made

--
nosy: +olberger

___
Python tracker 

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

[issue17776] IDLE Internationalization

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti, roger.serwy, terry.reedy
stage:  -> patch review
versions: +Python 2.7, Python 3.3, Python 3.4

___
Python tracker 

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

[issue14315] zipfile.ZipFile() unable to open zip File

[Void]

Void added the comment:

> FWIW, I think it will OK to just ignore extra fields that we can't 
> interpret as according to the standard.  The only one we currently
> care about is the "Zip64 extended information extra field".  Also,
> other programs (including the Info-Zip tools) seem to mostly ignore
> these fields.

Yes, please.

> The ellipsis is just a standard convention for indicating a repeating
> pattern.  Extra fields which are not multiples of four bytes are not
> properly formed.

. . .

[;pause;]

Totally agree.  But at the very least it should check the size and raise a 
proper exception (e.g. BadZipFile).

FWIW, the code is already avoiding proper bounds checking using the built-in 
behavior of slicing -- 

tp, ln = unpack(' I still don't see the bug; the module is behaving correctly - it is the 
> zipfile that is buggy. Supporting this specific kind of buggy zipfiles is a 
> new feature.

You realize that you are calling user-controlled data buggy, right?

--
nosy: +void.sender

___
Python tracker 

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

[issue17050] argparse.REMAINDER doesn't work as first argument

[paul j3]

paul j3 added the comment:

The problem isn't with REMAINDER, but with the distinction between optionals 
and arguments.  If you change '--def' to 'def', the parse should work:

>>> p = ArgumentParser(prog='test.py')
>>> p.add_argument('remainder', nargs=argparse.REMAINDER)
>>> p.parse_args(['def'])

'--def' would give problems with almost all of the nargs options, especially 
'*' and '?'.

The issue is that '--def' looks like an optional.  Since it is not found in the 
defined arguments, it is classed as an unknown extra and skipped (try 
p.parse_known_args(['--def'])).  All of this takes place before 'REMAINDER' has 
a chance to look at the argument strings.

In http://bugs.python.org/issue9334   I submitted a patch that defines a 
'args_default_to_positional' parser option.  If this is True, that unrecognized 
'--def' would be classed as a 'positional' and would be captured by the 
REMAINDER.

--
nosy: +paul.j3

___
Python tracker 

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

[issue17673] add `copy_from` argument to temporaryfile

[Kyle Roberts]

Kyle Roberts added the comment:

Very cool, I didn't think it'd be included in the patch for some reason. Thanks!

--

___
Python tracker 

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

[issue5492] Error on leaving IDLE with quit() or exit() under Linux

[Ger Luijten]

Ger Luijten added the comment:

Hello Roger,

To you and others that worked on this bug a big thanks for the extra deep
dig into the chain of events to find this old bug and fix it. Impressive!

Because I'm not familiar with the inner workings that cause this bug I was
wondering if the kill command you use is the structural solution or just a
clever workarond to prevent the error being written to the text widget and
forcing the program to stop abruptly.

For me your explanation raised the question if other processes that should
terminate normally are now prevented from doing so and for instance are not
able to do clear allocated memory (garbage collection).

Could you shed some light on your bug fix?

Greetings, Ger

2013/4/1 Roger Serwy 

>
> Roger Serwy added the comment:
>
> I found the root cause of the original error.
>
> Entering "exit()" at the shell raises SystemExit which gets written to the
> shell's text widget. The call to actually write the text passes through
> .write() in Lib/idlelib/OutputWindow.py, which calls text.update(). The
> call to .update() enters the Tk event loop and flushes pending events,
> including expired .after callbacks.
>
> Forcing the .after callback in .close() to 1 ms will always trigger the
> error. Commenting out the text.update() in OutputWindow.py avoids the error.
>
> The patch causes .kill_subprocess() to execute immediately which prevents
> the subprocess from writing to sys.stderr.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue17778] Fix test discovery for test_multiprocessing.py

[Zachary Ware]

New submission from Zachary Ware:

I think this one only didn't work with discovery by accident: the only change 
necessary to make discovery pass was to make _TestPoll match all other _Test* 
classes by inheriting from BaseTestCase instead of unittest.TestCase.  The 
remainder of the changes are to eliminate test_main by converting it instead to 
setUpModule.  setUpModule is, I think, necessary on this one due to a failing 
test in WithProcessesTestLogging when the initial call to 
multiprocessing.get_logger().setLevel() (originally in test_main) is moved to 
top-level code.

--
components: Tests
files: test_multiprocessing_discovery.diff
keywords: patch
messages: 187181
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_multiprocessing.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29905/test_multiprocessing_discovery.diff

___
Python tracker 

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

[issue17050] argparse.REMAINDER doesn't work as first argument

[paul j3]

paul j3 added the comment:

Here's a way of passing an optional-like argument to a subparser:

parser = argparse.ArgumentParser()
subparsers = parser.add_subparsers(dest='cmd')
sub1 = subparsers.add_parser('cmd')
sub1.add_argument('foo',nargs='*')
args = parser.parse_args('cmd -- --def 1 2 3'.split())

producing

Namespace(cmd='cmd', foo=['--def', '1', '2', '3'])

The  '--' forces the parser to treat '--def' as a positional.  If 
nargs='REMAINDER', foo=['--', '--def', ...].

But the following subparser definition would be even better:

   sub1.add_argument('--def', action='store_true')
   sub1.add_argument('rest',nargs='...')

Here the '--def' is handle explicitly, as opposed to being passed on.

You don't need the whole subparsers mechanism if you are just going to pass 
those arguments (unparsed) to another program.

--

___
Python tracker 

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

[issue17555] ForkAwareThreadLock leak after fork

[Richard Oudkerk]

Changes by Richard Oudkerk :


--
title: Creating new processes after importing multiprocessing.managers consumes 
more and more memory -> ForkAwareThreadLock leak after fork
versions: +Python 3.3, Python 3.4

___
Python tracker 

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

[issue17772] test_gdb doesn't detect a gdb built with python3.3 (or higher)

[Dave Malcolm]

Dave Malcolm added the comment:

I didn't know that gdb supported embedding Python 3.   Is this a set of patches 
you're applying downstream, or an official gdb feature?

If so, it means everyone coding to the gdb API needs to somehow make their 
FOO-gdb.py files be Python 3-compatible.  Currently the Tools/gdb/libpython.py 
is Python 2 compatible, and I'm sure there are going to be incompatibilities 
with python 3.

--

___
Python tracker 

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

[issue17772] test_gdb doesn't detect a gdb built with python3.3 (or higher)

[Matthias Klose]

Matthias Klose added the comment:

yes, this from the FSF 7.6 branch

--

___
Python tracker 

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

[issue17772] test_gdb doesn't detect a gdb built with python3.3 (or higher)

[Dave Malcolm]

Dave Malcolm added the comment:

Thanks.  Does upstream gdb have a plan dcoumented somewhere for how to deal 
with all of the FOO-gdb.py files.  Are they expected to be coded to the common 
Python 2/3 subset?

--

___
Python tracker 

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

[issue17618] base85 encoding

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> btoa/atob seems extinct.

At least half of ascii85 encoders in wild implement this variant.

I think we can provide a universal solution compatible (with some 
pre/postprocessing) with both variants. Enclose encoded data in <~ and ~> or 
not, and at which column wrap an encoded data. Padding can be easy implemented 
as preprocessing (data + (-len(data)) % 4 * b'\0').

As for Git/Mercurial's base85, what other applications use this encoding?

--

___
Python tracker 

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

[issue17618] base85 encoding

[Antoine Pitrou]

Antoine Pitrou added the comment:

Le mercredi 17 avril 2013 à 18:14 +, Serhiy Storchaka a écrit :
> I think we can provide a universal solution compatible (with some
> pre/postprocessing) with both variants. Enclose encoded data in <~ and
> ~> or not, and at which column wrap an encoded data. Padding can be
> easy implemented as preprocessing (data + (-len(data)) % 4 * b'\0').

That's ok with me. It's just more work for whoever does it :-)

> As for Git/Mercurial's base85, what other applications use this
> encoding?

I don't know, but they use it to produce binary diffs ("diff" chunks of
binary files), so any application wanting to parse Mercurial/Git diffs
would have to recognize base85 data.

(and I also like that the Mercurial/Git variant is the simpler of all
3 :-))

--

___
Python tracker 

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

[issue17673] add `copy_from` argument to temporaryfile

[Antoine Pitrou]

Antoine Pitrou added the comment:

Some comments about the patch:
- unless I'm missing something, I think you should re-use the fd instead of 
reopening the file by name
- it would be nice if copy_from accepted an open file-like object, e.g. a 
BytesIO instance
- I don't think you need a specific file for the test; just use an existing one 
(e.g. __file__, or one of the data files somewhere in the test subtree)
- the doc needs some "versionchanged" markers

--

___
Python tracker 

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

[issue17779] Fix test discovery for test_osx_env.py

[Zachary Ware]

New submission from Zachary Ware:

This patch converts test_osx_env.py to use a skip decorator instead of just not 
running the test at all.

--
components: Tests
files: test_osx_env_discovery.diff
keywords: patch
messages: 187189
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_osx_env.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29906/test_osx_env_discovery.diff

___
Python tracker 

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

[issue17780] the test suite should use a TEMPDIR in the build directory, not the source directory

[Matthias Klose]

New submission from Matthias Klose:

the test suite should use a TEMPDIR in the build directory, not the source 
directory, e.g. the source directory might not be writeable.

looks like regrtest._make_temp_dir_for_build() needs just to use abs_builddir 
instead of srcdir.

--
components: Tests
messages: 187190
nosy: doko
priority: normal
severity: normal
status: open
title: the test suite should use a TEMPDIR in the build directory, not the 
source directory
versions: Python 3.4

___
Python tracker 

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

[issue17781] optimize compilation options

[Antoine Pitrou]

New submission from Antoine Pitrou:

Ubuntu's system Python 3.3 shows consistently better performance than a vanilla 
Python 3.3: around 10-15% faster in general (see attached benchmark numbers).

If this can be attributed to different compilation options, it would be nice to 
backport those options to our standard build config.

--
components: Build
files: perflog.txt
messages: 187192
nosy: barry, doko, pitrou
priority: low
severity: normal
status: open
title: optimize compilation options
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file29907/perflog.txt

___
Python tracker 

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

[issue17618] base85 encoding

[Martin Morrison]

Martin Morrison added the comment:

> Using a trick with struct.unpack() has very unpleasant side effect.
> It might be a few speed up encoding, but creates the Struct object
> with the size is many times larger than the size of the processed
> data. Worse, this object is cached and continues to consume memory.
> Since the size of the data most likely will be unique, almost every
> call of b85encode creates a new object. This will lead to memory
> leaks.

Can you elaborate on this? What leakage is there? I assume this is some 
implementation quirk of the struct module that I'm not aware of.

> Le mercredi 17 avril 2013 à 18:14 +, Serhiy Storchaka a écrit :
>> I think we can provide a universal solution compatible (with some
>> pre/postprocessing) with both variants. Enclose encoded data in <~
>> and ~> or not, and at which column wrap an encoded data. Padding
>> can be easy implemented as preprocessing (data + (-len(data)) % 4 *
>> b'\0').
>
> That's ok with me. It's just more work for whoever does it :-)

As I mentioned in one of my previous comments, I was trying very hard 
not to touch the Mercurial solution (b85(en|de)code in the latest 
patch), and just copy it wholesale. Mostly, I don't really like the way 
the solution reads (unpythonic in my eyes), but can understand that for 
this kind of thing that might be the best way.

In my solution (a85(en|de)code) I wrote it from scratch in what I felt 
was a readable way. I can quite easily extend my version to support your 
description of the btoa/atob version (i.e. no bracketing, always pad, 
always wrap output).

I'm less convinced it's sensible to merge the ascii85 implementations 
and the Mercurial b85 one. If you really want that though, I would be in 
favour of using my a85 implementation and just changing the encode inner 
function to use the lookup table.

(we can do all this independently of the function names, which I think 
Antoine and I are agreed should be separate for the different 
implementations)

>> As for Git/Mercurial's base85, what other applications use this
>> encoding?
>
> I don't know, but they use it to produce binary diffs ("diff" chunks
> of binary files), so any application wanting to parse Mercurial/Git
> diffs would have to recognize base85 data.
>
> (and I also like that the Mercurial/Git variant is the simpler of
> all 3 :-))

I actually prefer the Ascii85 one for the simplicity of the encoding 
(shift base 85 chunks of the input by 33 to get into the printable ascii 
range) rather than the clunky lookup table approach. À chacun son goût. :-)

--

___
Python tracker 

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

[issue17781] optimize compilation options

[Matthias Klose]

Matthias Klose added the comment:

most of that can be attributed to the pgo build, which is upstream for a long 
time. the second thing to do is to build with lto, and see what speedups you 
get in addition. and it certainly helps to build the interpreter statically 
(without --enable-shared).

but thanks to confirming my own experience ;)

--

___
Python tracker 

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

[issue17761] platform._parse_release_file doesn't close the /etc/lsb-release file, doesn't know about 'Ubuntu'

[Antoine Pitrou]

Antoine Pitrou added the comment:

Can't you use a "with" statement instead of calling close() explicitly?

--
nosy: +lemburg, pitrou

___
Python tracker 

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

[issue17618] base85 encoding

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Can you elaborate on this? What leakage is there? I assume this is some 
implementation quirk of the struct module that I'm not aware of.

issue14596.

--

___
Python tracker 

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

[issue17618] base85 encoding

[Martin Morrison]

Martin Morrison added the comment:

>> Can you elaborate on this? What leakage is there? I assume this is some
> implementation quirk of the struct module that I'm not aware of.
>
> issue14596.

Thanks for the pointer. I will rework the patch for the encoder/decoders 
to use an explicit Struct so that the inbuilt cache gets bypassed and we 
don't "leak",

--

___
Python tracker 

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

[issue17782] Fix test_signal failure on x32

[Antoine Pitrou]

New submission from Antoine Pitrou:

x32 is a special Linux ABI on x86-64 CPUs. When compiling for x32, there's a 
failure in test_sigtimedwait. The failure is due to the fact that on x32, 
"long" is 32 bits but "timespec.tv_nsec" is 64 bits. Therefore we can't pass 
the pointer to tv_nsec directly to _PyTime_ObjectToTimespec.

Patch attached.

--
components: Interpreter Core
files: x32_timespec.patch
keywords: patch
messages: 187197
nosy: haypo, mark.dickinson, pitrou
priority: low
severity: normal
stage: patch review
status: open
title: Fix test_signal failure on x32
type: crash
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29908/x32_timespec.patch

___
Python tracker 

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

[issue17782] Fix test_signal failure on x32

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
type: crash -> behavior

___
Python tracker 

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

[issue17618] base85 encoding

[Antoine Pitrou]

Antoine Pitrou added the comment:

Serhiy, Martin, perhaps one of you could report the potential memory leak on 
the Mercurial bug tracker: http://bz.selenic.com/

--

___
Python tracker 

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

[issue17783] run the testsuite in batched mode

[Matthias Klose]

New submission from Matthias Klose:

running all the tests in one batch sometimes can go wrong. there is of course 
the --single mode, but starting the testsuite for each single test seems to be 
a bit of overhead.  So extend the --single API to something like --next= 
which runs the next  tests. or would --batch be a better name? and maybe 
don't change the single default parameter in the signature, and introduce a new 
parameter.

the proposed patch is currently against the 3.3 branch, and without doc changes.

--
components: Tests
files: batch-test.diff
keywords: patch
messages: 187199
nosy: doko
priority: normal
severity: normal
stage: patch review
status: open
title: run the testsuite in batched mode
versions: Python 3.4
Added file: http://bugs.python.org/file29909/batch-test.diff

___
Python tracker 

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

[issue13831] get method of multiprocessing.pool.Async should return full traceback

[Paul Winkler]

Changes by Paul Winkler :


--
nosy: +slinkp

___
Python tracker 

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

[issue13831] get method of multiprocessing.pool.Async should return full traceback

[Paul Winkler]

Changes by Paul Winkler :


--
versions: +Python 3.3

___
Python tracker 

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

[issue17782] Fix test_signal failure on x32

[STINNER Victor]

STINNER Victor added the comment:

The patch looks good to me.

--

___
Python tracker 

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

[issue17777] Unrecognized string literal escape sequences give SyntaxErrors

[Reynir Reynisson]

Reynir Reynisson added the comment:

Thank you for the quick reply. Yes, something along those lines would help. 
Maybe adding "The escape sequence \x expects exactly two hex digits" would make 
it even clearer.

--

___
Python tracker 

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

[issue17782] Fix test_signal failure on x32

[Roundup Robot]

Roundup Robot added the comment:

New changeset 7a0fb0f59cf6 by Antoine Pitrou in branch '3.3':
- Issue #17782: Fix undefined behaviour on platforms where ``struct 
timespec``'s "tv_nsec" member is not a C long.
http://hg.python.org/cpython/rev/7a0fb0f59cf6

New changeset f9e0eacb6b13 by Antoine Pitrou in branch 'default':
Issue #17782: Fix undefined behaviour on platforms where ``struct timespec``'s 
"tv_nsec" member is not a C long.
http://hg.python.org/cpython/rev/f9e0eacb6b13

--
nosy: +python-dev

___
Python tracker 

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

[issue17782] Fix test_signal failure on x32

[Antoine Pitrou]

Antoine Pitrou added the comment:

Committed!

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue14174] argparse.REMAINDER fails to parse remainder correctly

[paul j3]

paul j3 added the comment:

An alternative to Jason's example:

parser = argparse.ArgumentParser()
parser.add_argument('app')
parser.add_argument('--config')
parser.add_argument('app_args', nargs=argparse.REMAINDER)
args = parser.parse_args(['--config', 'bar', 'app'])
print vars(args)
# as expected: {'app': 'app', 'app_args': [], 'config': 'bar'}

When you have several positionals, one or more of which may have 0 arguments 
(*,?,...), it is best to put all of the optional arguments first.  

With 'app --config bar', parse_args identifies a 'AOA' pattern (argument, 
optional, argument).  It then checks which positional arguments match.  'app' 
claims 1, 'app_args' claims 2 (REMAINDER means match everything that follows).  
That leaves nothing for '--config'.

What you expected was that 'app' would match with the 1st string, '--config' 
would match the next 2, leaving nothing for 'app_args'.  

In http://bugs.python.org/issue14191 I wrote a patch that would give the 
results you want if 'app_args' uses '*'.  That is makes it possible to 
interleave positional and optional argument strings.  But it does not change 
the behavior of REMAINDER.

parser.add_argument('app_args', nargs='*')

--

Maybe the documentation example for REMAINDER needs to modified to show just 
how 'greedy' REMAINDER is.  Adding a:

parser.add_argument('--arg1',action='store_true')

does not change the outcome.  REMAINDER still grabs '--arg1' even though it is 
a defined argument.


Namespace(arg1=False, args=['--arg1', 'XX', 'ZZ'], command='cmd', foo='B')

--
nosy: +paul.j3

___
Python tracker 

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

[issue17555] ForkAwareThreadLock leak after fork

[Roundup Robot]

Roundup Robot added the comment:

New changeset 66731a1b1aa4 by Richard Oudkerk in branch '2.7':
Issue #17555: Fix ForkAwareThreadLock so that size of after fork
http://hg.python.org/cpython/rev/66731a1b1aa4

New changeset 21314f27a40c by Richard Oudkerk in branch '3.3':
Issue #17555: Fix ForkAwareThreadLock so that size of after fork
http://hg.python.org/cpython/rev/21314f27a40c

New changeset 2c350a75ff43 by Richard Oudkerk in branch 'default':
Issue #17555: Fix ForkAwareThreadLock so that size of after fork
http://hg.python.org/cpython/rev/2c350a75ff43

--
nosy: +python-dev

___
Python tracker 

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

[issue14174] argparse.REMAINDER fails to parse remainder correctly

[paul j3]

paul j3 added the comment:

By the way, parser.parse_args() uses parse_known_arg().  parse_known_args 
returns a Namespace and a list of unknown arguments.  If that list is empty, 
parse_args returns the Namespace.  If the list is not empty, parse_args raises 
an error.

So parse_known_args does not change how arguments are parsed.  It just changes 
how the unknowns are handled.

--

___
Python tracker 

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

[issue17694] Enhance _PyUnicodeWriter API to control minimum buffer length without overallocation

[Roundup Robot]

Roundup Robot added the comment:

New changeset edf029fc9591 by Victor Stinner in branch 'default':
Close #17694: Add minimum length to _PyUnicodeWriter
http://hg.python.org/cpython/rev/edf029fc9591

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue17784] the test suite should honor an http_proxy for running the test suite

[Matthias Klose]

New submission from Matthias Klose:

the test suite should honor an http_proxy for running the test suite, at least 
for all the tests using the urlfetch resource. maybe for some tests using the 
network resource too. this would allow running tests in somehow constrained 
environments.

--
components: Tests
messages: 187208
nosy: doko
priority: normal
severity: normal
status: open
title: the test suite should honor an http_proxy for running the test suite

___
Python tracker 

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

[issue17760] No i18n of IDLE's interface in french

[Terry J. Reedy]

Terry J. Reedy added the comment:

Oliver opened thread " I18n of IDLE's interface ?" on idle-dev list.

--

___
Python tracker 

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

[issue17760] No i18n of IDLE's interface in french

[Ezio Melotti]

Ezio Melotti added the comment:

FTR, here is a link to thread: 
http://mail.python.org/pipermail/idle-dev/2013-April/003254.html.
There's also a follow-up issue with a patch: #17776.

http://mail.python.org/pipermail/idle-dev/2013-April/003258.html also has a 
list of reasons to avoid internationalization, and 4 is one of the main reasons 
I'm against it.
Students already have to learn several English words anyway (e.g. keywords like 
if, else, for, while, class, try, except, finally, break, continue, etc.; 
functions like all, any, print, input, range, sorted, reversed, etc.; 
"concepts" like classes, functions, methods, variables, attributes, etc.).  
Adding a few more (open, close, save, exit, cut, copy, paste, find, etc.) is 
not going to make a lot of difference anyway.

--

___
Python tracker 

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

[issue17694] Enhance _PyUnicodeWriter API to control minimum buffer length without overallocation

[STINNER Victor]

STINNER Victor added the comment:

The commit changes the default value of min_length when overallocation is 
enabled: it does not use at least 100 characters anymore. It did not directly 
introduce a bug, but the regression comes from 7ed9993d53b4 (use 
_PyUnicodeWriter for Unicode decoders). The following commits should fix these 
issues.

changeset:   83435:94d1c3bdb79c
tag: tip
user:Victor Stinner 
date:Thu Apr 18 00:25:28 2013 +0200
files:   Objects/unicodeobject.c
description:
Fix bug in Unicode decoders related to _PyUnicodeWriter

Bug introduced by changesets 7ed9993d53b4 and edf029fc9591.


changeset:   83434:7eb52460c999
user:Victor Stinner 
date:Wed Apr 17 23:58:16 2013 +0200
files:   Objects/unicodeobject.c
description:
Fix typo in unicode_decode_call_errorhandler_writer()

Bug introduced by changeset 7ed9993d53b4.

--

___
Python tracker 

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

[issue16142] ArgumentParser inconsistent with parse_known_args

[paul j3]

paul j3 added the comment:

parser = argparse.ArgumentParser()
parser.add_argument('-k','--known',action='store_true')
print(parser.parse_known_args(['-k','-u']))
print(parser.parse_known_args(['-ku']))
print(parser.parse_known_args(['-uk']))

I think you want these 3 cases to produce the same output:

(Namespace(known=True), ['-u'])

With the attached patch, '-ku' produces the same result as '-k -u'. Instead of 
raising the "ignored explicit argument 'u'" error, if puts '-u' in the 'extras' 
list.  'parse_args' then raises a "error: unrecognized arguments: u" error.

That's an easy change, and does not break anything in the 'test_argparse.py' 
file.  But keep in mind that this test file mostly uses 'parse_args', and 
usually it ignores the failure messages.

Getting '-uk' to work this way would be much harder.  While it isn't obvious 
from the documentation, '-uk' is a valid option string, and '-u' is a valid 
abbreviation. Notice in 16.4.4.1. of the documentation, the difference between 
long and short options is based on the number of characters, not whether there 
it starts with '-' or '--'.  So identifying what is wrong with '-uk' would 
require ambiguous reasoning.

I wonder what optparse does.

--
keywords: +patch
nosy: +paul.j3
Added file: http://bugs.python.org/file29910/dashku.patch

___
Python tracker 

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

[issue17618] base85 encoding

[Martin Morrison]

Martin Morrison added the comment:

New diff. Changes from the last one:

- change in struct handling to avoid issue14596

- Addition of btoa85 and atob85 functions that do legacy 'btoa' 
encoding/decoding. These are just wrappers around a85(en|de)code, which now 
have additional keyword args to control wrapping, padding, framing, and 
whitespace skipping

- New tests covering all 3 variants

--
Added file: http://bugs.python.org/file29911/issue17618-4.diff

___
Python tracker 

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

[issue17135] imp doc should direct to importlib

[Roundup Robot]

Roundup Robot added the comment:

New changeset f22c463ce73c by R David Murray in branch 'default':
#17135: mark imp as deprecated as of 3.4.
http://hg.python.org/cpython/rev/f22c463ce73c

--
nosy: +python-dev

___
Python tracker 

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

[issue17555] ForkAwareThreadLock leak after fork

[Richard Oudkerk]

Changes by Richard Oudkerk :


--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue17785] Use faster URL shortener for perf.py

[Alexandre Vassalotti]

New submission from Alexandre Vassalotti:

As noted previously, TinyURL URL shortening API is rather slow and not always 
available. Each requests takes between 0.5 and 1.5 seconds.

We should change it to use Google URL Shortener which returns a response within 
10 milliseconds and is much more available.

--
assignee: alexandre.vassalotti
components: Benchmarks
files: use_google_shortener.patch
keywords: patch
messages: 187215
nosy: alexandre.vassalotti, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Use faster URL shortener for perf.py
type: performance
Added file: http://bugs.python.org/file29912/use_google_shortener.patch

___
Python tracker 

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

[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

[Ben Hoyt]

Ben Hoyt added the comment:

Okay, I'm looking at the diff between mt-tip-noregistry.txt and 
mt-tip-newregistry.txt, and I've attached a file showing the lines that are 
*different* between the two, as well as the Apache mime.types value for that 
file extension.

In most cases, noregistry gives the right mime type, and newregistry is wrong. 
However, in a few cases, the registry value is right (i.e., according to 
Apache's mime.types). However, I think that's a totally separate issue, and 
maybe we should probably open a bug to update a few of the hard-coded mappings 
in mimetypes.py.

The cases where noregistry is right (according to Apache):

* .aif
* .aifc
* .aiff
* .avi
* .sh
* .wav
* .xsl
*. zip

The cases where noregistry is wrong (according to Apache):

* .bmp is hard-coded as "image/x-ms-bmp", but it should be image/bmp
* .dll and .exe are hard-coded as "application/octet-stream", but should be 
"application/x-msdownload"
* .ico is hard-coded as "image/vnd.microsoft.icon" but should be "image/x-icon"
* .m3u is hard-coded as "application/vnd.apple.mpegurl" but should be 
"audio/x-mpegurl"

None of these are standardized IANA mime types, and they're not particularly 
common for web servers to be serving, so it probably doesn't matter too much 
that the current hard-coded values are wrong. Also, I'm guessing web browsers 
will interpret the older type image/x-ms-bmp as image/bmp anyway. So maybe we 
should open another issue to fix the hard-coded types in mimetypes.py shown 
above, but again, that's another issue.

The other thing here is all the *new types* that the registry adds, such as 
".acrobatsecuritysettings". I don't see that these add much value -- just a 
bunch of types that depend on the programs you have installed. And in my mind 
at least, the behaviour of mimetypes.guess_type() should not change based on 
what programs you have installed.

In short, "noregistry" gives more accurate results in most cases that matter, 
and I still strongly feel we should revert to that. (The only alternative, in 
my opinion, is to switch to Dave Chambers' version of read_windows_registry(), 
but not call it by default.)

--
Added file: http://bugs.python.org/file29913/different.txt

___
Python tracker 

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

[issue17742] Add _PyBytesWriter API

[STINNER Victor]

STINNER Victor added the comment:

Here is a benchmark. It looks like the overallocation is not configured 
correctly for charmap and UTF-8 encoders: it is always enabled for UTF-8 
encoder (whereas it should only be enabled on the first call to an error 
handler), and never enabled for charmap encoder.

--
Added file: http://bugs.python.org/file29914/bench_encoders.compare

___
Python tracker 

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

[issue17530] pprint could use line continuation for long bytes literals

[Pam McA'Nulty]

Pam McA'Nulty added the comment:

Here's a new version.  It looks more like the str_parts patch and uses 
parentheses instead of continuation as suggested.

Sample output:
>>> pprint.pprint(b"\n\na\x00", width=1)
   (b'\n'
b'\n'
b'a'
b'\x00')

--
Added file: http://bugs.python.org/file29915/bytes_pprint2.patch

___
Python tracker 

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

[issue17776] IDLE Internationalization

[Terry J. Reedy]

Terry J. Reedy added the comment:

Whether and how much to internationalize Idle is being discussed on idle-dev 
thread "I18n of IDLE's interface ?". I was going to suggest there that the menu 
system would be the first place to start. A prime concern for me is that we not 
break anything (hence some of the questions below), and the menu labels seem 
relatively safe (compared to format strings -- see post on thread).

While locale is used to format dates and times, I believe this would be the 
first use of gettext within the stdlib itself. To me it is a plausible to do 
because the idlelib modules are used to write and run code rather than being 
imported into code. I still have this concern: if a beginner can manage to 
handle 'English' keywords, builtin names, and exception names and messages*, 
does having translated menu labels give enough benefit to be worth the bother? 
I am open to the answer being yes, but before I were to commit this patch to 
the CPython repository, I would like to see a working example translation and a 
report of a field test with real students.

(* I an not including stdlib because many beginners programs make little use of 
imports.)

As for the patch: It looks good as far as it goes, but I have little knowledge 
of locale and gettext beyond the bare bones and no experience with either. The 
gettext doc is not all that clear to me, and it seems exclusively unix-focused, 
whereas I am on Windows. My questions:

1. Does it actually work on Windows (and Mac), without bugs?
(I could sometime look as test_gettext and try it on Windows, but not on the 
machine I am on at the moment.)

2. +gettext.bindtextdomain('idlelib')
What does this actually do. Where do .mo files go on the various OSes. This 
sort of doc has to be part of a patch.

3. Does the gettext machinery look at an environmental locale variable behind 
the scenes? Is that how it decides on the translation language, if any?

4. +_ = gettext.gettext
Leave aside the issue of doing the binding in builtins versus each module, as 
in the patch (this seems safer). The doc is skimpier than I would like: "Return 
the localized translation of message, based on the current global domain, 
language, and locale directory." The latter part is part of my question above.

As for the first part: is the default behavior to simply echo the text passed 
in? If Idle executes in a non-default environment/locale, but there is no 
translation file, does it echo the original string (English) or raise an 
exception? Same question if there is an appropriate translation file but no 
entry for the particular string? Overall, does gettext *ever* raise an 
exception, or does it *always* return a string of the correct type, or might it 
return bytes when unicode is expected (in 3.x)? In other words, can replacing a 
string literal with a gettext call cause Idle to crash?

5. Focusing only on the menus, do you expect anything more applied to the 
repository than a patch like this and a doc patch? Who do you see as running 
Tools/i18n/pygettext.py, a core dev, one other person, or each translator? What 
do you see happening with the .pot file for each release? Include it with the 
release? Distribute on pypi? or regenerate it by each translator? And what 
about .mo files? It would seem silly to have multiple French .mo files, 
although I can imaging that different teachers might disagree on the best 
translation for their students ;-).

Let me put is another way. The patch by itself is useless. In fact, even if it 
is completely transparent to users, it will *not* be transparent to Idle 
developers working on the code. It will actually be a detriment* unless there 
is additional work done. Who do you two, or any other advocates of IdleIl8n 
envision as doing the various tasks needed to make it useful?

Perhaps there should be an IdleIl8n project on PyPI. In fact, such a project 
could be done without 'official' cooperation. If indeed there is no such 
project, I would wonder whether such absence indicates an absence of need. Or 
is it knowledge of how? Testing something as a 3rd party distribution and 
getting community acceptance is one normal way for things to get added to the 
stdlib.

(6, Suppose English speaking teachers or user might want to customize the menu 
labels. Can that also be done with .gettext?)

* Besides uglifying the code a bit, this patch will break any existing patches 
on the tracker that target the same lines and make tracing the history of any 
patched line through hg annotate harder.

Thought also needs to be given to the extension mechanism. As I understand it, 
pygettest.py will not pick up menu entries dynamically added by extensions. 
Roger, the extension expert, might comment on this.

--
stage: patch review -> test needed

___
Python tracker 

___
___
Python-bugs-l

[issue17721] Help button on preference window doesn't work

[Todd Rovito]

Changes by Todd Rovito :


--
nosy: +Todd.Rovito

___
Python tracker 

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

[issue17532] IDLE: Always include "Options" menu on MacOSX

[Todd Rovito]

Todd Rovito added the comment:

I tested the patch on OS X 10.8 and it works perfect!!!

Thanks Guilherme.

--

___
Python tracker 

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

[issue17776] IDLE Internationalization

[Todd Rovito]

Changes by Todd Rovito :


--
nosy: +Todd.Rovito

___
Python tracker 

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

[issue4140] urllib2: request with digest auth through proxy fail

[Senthil Kumaran]

Senthil Kumaran added the comment:

Yes, RFC specifically states that "The absoluteURI form is REQUIRED when the 
request is being made to a proxy." Thanks Jessica for making a note of that. 
Closing this issue as Invalid.

--
dependencies:  -urllib2 fails against IIS 6.0 (No support for MD5-sess auth)
resolution: accepted -> invalid
stage: test needed -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue17532] IDLE: Always include "Options" menu on MacOSX

[Roger Serwy]

Roger Serwy added the comment:

Hi Guilherme, 

Have you signed the contributor agreement? It can be found at: 
http://www.python.org/psf/contrib/contrib-form/

Your patch looks good to me, but I don't have a Mac to test against. I trust 
Todd's test that it works on the latest MacOSX version. Hopefully it works on 
earlier OSX versions as well. (I think it should, but Tk on Mac has been 
problematic.)

--

___
Python tracker 

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

[issue17721] Help button on preference window doesn't work

[Roger Serwy]

Roger Serwy added the comment:

This falls under annoyance #11 from issue13504. I'll cross-reference it there.

--
nosy: +roger.serwy

___
Python tracker 

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

[issue13504] Meta-issue for "Invent with Python" IDLE feedback

[Roger Serwy]

Roger Serwy added the comment:

Issue17721 addresses part of point 11) "And am I the only person who noticed 
that the Help button doesn’t actually do anything?"

--
dependencies: +Help button on preference window doesn't work

___
Python tracker 

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

[issue5492] Error on leaving IDLE with quit() or exit() under Linux

[Roger Serwy]

Roger Serwy added the comment:

Hello Ger,

Sure, I can explain. IDLE is driven by the Tk event loop. Calls to .update() 
flushes all pending events and expired .after callbacks. 

When close() gets called in PyShell, it places the finalization of the close 
(using close2()) into the Tk event queue as a .after callback. Now, when the 
error message arrives over RPC to the PyShell, it is written to the .text 
widget using the write() method. Here's a snippet from PyShell.py:

self.text.mark_gravity("iomark", "right")
count = OutputWindow.write(self, s, tags, "iomark")
self.text.mark_gravity("iomark", "left")

The OutputWindow.write() command eventually calls .update() before returning. 
That .update() call may flush the close2() callback if the timer expired. If 
so, then .text gets set to None. The next line to restore the gravity to the 
left is doing an attribute lookup for "mark_gravity" on None which causes the 
error.

I hope that clarifies why the patch works.

Can someone verify that the patch works? I've managed to convince myself of its 
validity, but it is always good to get another set of eyes on it in case I 
missed something.

--
assignee:  -> roger.serwy
stage: test needed -> patch review

___
Python tracker 

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