Jon Heiner | 30 Mar 23:27 2015

[issue23816] struct.unpack returns null pascal strings - [first] bug report


New submission from Jon Heiner:

I believe there is an issue with the _struct.c handling of Pascal style strings.

In the _struct.c:s_unpack_internal() function (reading 2.7.6 and 2.7.9 source from tgz ball), the size
parameter 'n' is clamped to code->size-1.

As far as I can tell, 'n' is set to the correct deserialized value, but the code->size value is not set to 255. I
could be incorrect, as I'm not running in a debugger.

I've attached a short repro case. Note the use of unpack_from() as otherwise unpac() will thrown an error.
Additionally, I may be using it wrong, but this feels correct.

----------
components: Library (Lib)
files: unpack_pascal.py
messages: 239644
nosy: jonheiner, mark.dickinson, meador.inge
priority: normal
severity: normal
status: open
title: struct.unpack returns null pascal strings - [first] bug report
versions: Python 2.7
Added file: http://bugs.python.org/file38745/unpack_pascal.py

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue23816>
_______________________________________
(Continue reading)

Serhiy Storchaka | 30 Mar 21:56 2015

[issue23815] Segmentation fault when create _tkinter objects


New submission from Serhiy Storchaka:

In 2.7 and 3.3:

>>> import _tkinter
>>> _tkinter.Tcl_Obj()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create '_tkinter.Tcl_Obj' instances
>>> _tkinter.TkttType()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create 'tktimertoken' instances

In 3.4+:

>>> import _tkinter
>>> _tkinter.Tcl_Obj()
Segmentation fault (core dumped)

And the same for _tkinter.TkttType.

Looks as this is a result of issue15721.

----------
components: Extension Modules, Tkinter
messages: 239636
nosy: Robin.Schreiber, amaury.forgeotdarc, asvetlov, loewis, ned.deily, pitrou, serhiy.storchaka
priority: normal
(Continue reading)

Karl O. Pinc | 30 Mar 20:40 2015

[issue23814] argparse: Parser level defaults do not always override argument level defaults


New submission from Karl O. Pinc:

In the argparse library parser library, contrary to the documentation,
parser-level defaults do not always override argument-level defaults.

https://docs.python.org/3.5/library/argparse.html#argparse.ArgumentParser.set_defaults

says "Note that parser-level defaults always override argument-level defaults:"

(And so does the python 3.3 docs.)

The docs then provide this example:

  >>> parser = argparse.ArgumentParser()
  >>> parser.add_argument('--foo', default='bar')
  >>> parser.set_defaults(foo='spam')
  >>> parser.parse_args([])
  Namespace(foo='spam')

But it is only true that parser-level defaults override argument-level
defaults when they are established after the argument is added.

The output below shows an argument level default overrideing
a parser level default.

$ python3
Python 3.3.2 (default, Jun  4 2014, 11:36:37) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
(Continue reading)

Serhiy Storchaka | 30 Mar 20:35 2015

[issue23813] RSS and Atom feeds of buildbot results are broken


New submission from Serhiy Storchaka:

There are links to Atom and RSS feeds on https://www.python.org/dev/buildbot/:

http://buildbot.python.org/all/rss
http://buildbot.python.org/all/atom

Both referred pages are broken.

web.Server Traceback (most recent call last):
exceptions.UnicodeDecodeError: 'utf8' codec can't decode byte 0xfc in position 39: invalid start byte
/usr/lib/python2.7/dist-packages/twisted/web/server.py:189 in process
188                    self._encoder = encoder
189            self.render(resrc)
190        except:
/usr/lib/python2.7/dist-packages/twisted/web/server.py:238 in render
237        try:
238            body = resrc.render(self)
239        except UnsupportedMethod as e:
/data/buildbot/lib/python/buildbot/status/web/feeds.py:55 in render
54    def render(self, request):
55        data = self.content(request)
56        request.setHeader("content-type", self.contentType)
/data/buildbot/lib/python/buildbot/status/web/feeds.py:224 in content
223                        for line in logdata.split('\n')[-30:]:
224                            unilist.append(unicode(line,'utf-8'))
225                        log_lines.extend(unilist)
exceptions.UnicodeDecodeError: 'utf8' codec can't decode byte 0xfc in position 39: invalid start byte

(Continue reading)

Gustavo J. A. M. Carneiro | 30 Mar 15:59 2015

[issue23812] asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost


New submission from Gustavo J. A. M. Carneiro:

I have a pattern where I read from a queue with a timeout, generally like this:

while True:
  reader = asyncio.async(wait_for(queue.get(), 0.1))
  try:
    item = (yield from reader)
  except asyncio.TimeoutError:
    reader.cancel()
    continue

This is to have a loop where we try to get items from the queue with a timeout.  Prior to Python 3.5, wait_for()
doesn't automatically cancel the reading task, so I have to do it explicitly above.

The code has a strange race condition where, if a taks calls put_nowait on a reader task that is just about to
be cancelled due to timeout, then the item that wast put onto the queue gets lost.

In the tests framework, the minimal test case I can come up with is mainly this code:

  q = asyncio.Queue(loop=loop)
  reader = loop.create_task(q.get())
  loop.run_until_complete(asyncio.sleep(0.01, loop=loop))

  q.put_nowait(1)
  q.put_nowait(2)
  reader.cancel()

When the reader gets cancelled, the item `1` is lost into the ether, and when you create another reader for
(Continue reading)

Akshet Pandey | 30 Mar 13:58 2015

[issue23811] Python py_compile error message inconsistent and missing newline


New submission from Akshet Pandey:

On the following test file (test.py):

```python
class Solution:
  def repeatedNumber(self, A):
    test = 1
      return []
```

Running python -m py_compile test.py return the following error message:
Sorry: IndentationError: unexpected indent (test.py, line 6)

But without a newline on stderr at the end of the message. This causes some problems with scripts that expect
a newline and new my particular case with reading stderr on docker where docker just ignore the line if it
doesn't end in a newline.

Also, this message differs from the runtime error message:

```
  File "test.py", line 6
    return []
    ^
IndentationError: unexpected indent
```

Would it be possible to at least add in a newline and at best, change the message to be consistent with the
runtime error message?
(Continue reading)

[issue23810] Suboptimal stacklevel of deprecation warnings for formatter and imp modules


New submission from Arfrever Frehtes Taifersar Arahesis:

https://hg.python.org/cpython/rev/2a336cc29282 changed stacklevel of some deprecation warnings.
However new value is still not useful, because either _frozen_importlib or importlib/_bootstrap.py is
now mentioned in deprecation warnings:

$ cat test.py
import formatter
import imp
$ python3.4 -Wd test.py
/usr/lib64/python3.4/formatter.py:24: PendingDeprecationWarning: the formatter module is
deprecated and will be removed in Python 3.6
  'Python 3.6', PendingDeprecationWarning)
/usr/lib64/python3.4/imp.py:32: PendingDeprecationWarning: the imp module is deprecated in favour
of importlib; see the module's documentation for alternative uses
  PendingDeprecationWarning)
$ python3.5 -Wd test.py
_frozen_importlib:321: DeprecationWarning: the formatter module is deprecated and will be removed in
Python 3.6
/usr/lib64/python3.5/importlib/_bootstrap.py:321: PendingDeprecationWarning: the imp module is
deprecated in favour of importlib; see the module's documentation for alternative uses
  return f(*args, **kwds)

----------
assignee: brett.cannon
components: Library (Lib)
messages: 239554
nosy: Arfrever, brett.cannon
priority: normal
(Continue reading)

Nick Coghlan | 30 Mar 03:00 2015

[issue23809] RFE: emit a warning when a module in a traceback shadows a stdlib module


New submission from Nick Coghlan:

A colleague just ran into the issue where they created a "json.py" module in their local directory and broke
a previously working program. I picked up on the mistake when I saw the following traceback snippet:

    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/lib/python2.7/site-packages/praw/__init__.py", line 27, in <module>
        import json
      File "json.py", line 1, in <module>
        r = requests.get("http://www.reddit.com/user/spilcm/about/.json")

However, actually making the connection required thinking "Wait, why is the stdlib JSON module calling
out to Reddit?" followed immediately by "Oh, that's not the stdlib json module".

That connection would potentially be easier for new Python users to make if there was an inline
notification printed after the traceback warning of the stdlib module shadowing. If nothing else, it
would give them something specific to search for to lead them to a discussion of name shadowing and the
problems that can arise when you name one of your local modules the same as a standard library module.

Offering such a feature would necessarily rely on having a standard way of getting a programmatic list of
the standard library modules available to the running interpreter version without actually loading
them all, a question which is discussed further in
https://stackoverflow.com/questions/6463918/how-can-i-get-a-list-of-all-the-python-standard-library-modules
and https://github.com/jackmaney/python-stdlib-list

Since the contents of the standard library for a given release is immutable, and we'd like to keep any such
mechanism (if we decide to provide it) very simple so we can easily access it from the low level interpreter
traceback machinery, my suggestion would be along the lines of:
(Continue reading)

Serhiy Storchaka | 29 Mar 20:45 2015

[issue23808] Symlink to directory on Windows 8


New submission from Serhiy Storchaka:

Looks as a symlink on Windows 8 can has the FILE_ATTRIBUTE_DIRECTORY flag.

http://buildbot.python.org/all/builders/AMD64%20Windows8%203.4/builds/348/steps/test/logs/stdio
======================================================================
FAIL: test_walk_bottom_up (test.test_os.WalkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File &#34;D:\buildarea\3.4.bolen-windows8\build\lib\test\test_os.py&#34;, line 802, in test_walk_bottom_up
    self.sub2_tree)
AssertionError: Tuples differ: (&#39; <at> test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;broken_link&#39;,
&#39;link&#39;], [&#39;tmp3&#39;]) != (&#39; <at> test_3872_tmp\\TEST1\\SUB2&#39;,
[&#39;link&#39;], [&#39;broken_link&#39;, &#39;tmp3&#39;])

First differing element 1:
[&#39;broken_link&#39;, &#39;link&#39;]
[&#39;link&#39;]

- (&#39; <at> test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;broken_link&#39;, &#39;link&#39;], [&#39;tmp3&#39;])
?                                                 ----------

+ (&#39; <at> test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;link&#39;], [&#39;broken_link&#39;, &#39;tmp3&#39;])
?                                 ++++++++++

======================================================================
FAIL: test_walk_prune (test.test_os.WalkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
(Continue reading)

Thana Annis | 29 Mar 17:42 2015

[issue23807] Improved test coverage for calendar.py command line


New submission from Thana Annis:

Added a test to ensure that --locale cannot be called without --encoding. This is targeting lines 654-656
of calendar.py.

----------
components: Tests
files: test_calendar.patch
keywords: patch
messages: 239494
nosy: Bwaffles
priority: normal
severity: normal
status: open
title: Improved test coverage for calendar.py command line
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38727/test_calendar.patch

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue23807>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-python-bugs-list%40m.gmane.org

R. David Murray | 29 Mar 16:56 2015

[issue23806] documentation for no_proxy is missing from the python3 urllib documentation


New submission from R. David Murray:

no_proxy (and what notation it supports) is mentioned in the python2 urllib docs, but not in the python3 docs.

----------
assignee: docs <at> python
components: Documentation
messages: 239493
nosy: docs <at> python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: documentation for no_proxy is missing from the python3 urllib documentation
type: behavior
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report <at> bugs.python.org>
<http://bugs.python.org/issue23806>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-python-bugs-list%40m.gmane.org


Gmane