Matt Bachmann | 24 Apr 08:40 2014

[issue21343] os.path.relpath returns inconsistent types


New submission from Matt Bachmann:

I noticed an issue passing in unicode to os.path.relpath.

Specifically that in some cases when passing in unicode I would get back unicode and others I would get back a
string. Below I demonstrate the issue. I also attached a patch.

Is this an issue or am I misunderstanding something. Is the patch reasonable? Totally willing to improve
and i'll admit I cannot test the ntpath version.

Python 2.7.6 (default, Apr  9 2014, 11:48:52)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.path.relpath(u'.', u'.')
'.'
>>> os.path.relpath(u'.', u'../')
u'bachmann'

----------
components: Library (Lib)
files: reldir.patch
keywords: patch
messages: 217119
nosy: Matt.Bachmann
priority: normal
severity: normal
status: open
title: os.path.relpath returns inconsistent types
(Continue reading)

Steinn Steinsen | 24 Apr 08:00 2014

[issue21342] multiprocessing RLock and Lock raise incorrect exceptions when releasing an unlocked lock.


New submission from Steinn Steinsen:

In the documentation of multiprocessing the locks, RLock and Lock, 
are said to be clones of their respective threading synchronization primitives.

There is an inconsistency in what exceptions are raised when an
unlocked lock is released. According to the threading documentation a 
RuntimeError should be raised.

Lock.release raises ValueError 
RLock.release raises AssertionError

Tested this in python 2.7, 3.2, 3.4, 3.5 and broken in all those versions.

The attached patch fixes this for 3.5

----------
components: Library (Lib)
files: release_exceptions.patch
keywords: patch
messages: 217117
nosy: steinn
priority: normal
severity: normal
status: open
title: multiprocessing RLock and Lock raise incorrect exceptions when releasing an unlocked lock.
type: behavior
versions: Python 2.7, Python 3.2, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35017/release_exceptions.patch
(Continue reading)

Barron | 24 Apr 06:12 2014

[issue21341] Configuring 'font' with ttk.Style for 'TEntry' does not change displayed font


New submission from Barron:

After using the configure() method of a ttk.Style object to configure the font of TEntry, Entry widgets
will still have the original default font.

The following 6 lines will demonstrate this in IDLE:

>>> from tkinter import ttk
>>> s = ttk.Style()
>>> s.configure('TButton', font = ('Courier', 24))
>>> s.configure('TEntry', font = ('Courier', 24))
>>> ttk.Button(text = 'Button').pack()
>>> ttk.Entry().pack()

The Button will be displayed using the newly configured font, but the Entry widget will retain the default font.

Calling the lookup() method after the above code reveals the following:

>>> s.lookup('TEntry', 'font')
'Courier 24'

This shows that the font property for TEntry is getting set properly, but it is not being displayed.

Configuring the font property directly on individual Entry widgets does display correctly.

----------
components: Tkinter
messages: 217114
nosy: barron
(Continue reading)

Jack Murray | 24 Apr 04:13 2014

[issue21340] Possible bug in asyncio


New submission from Jack Murray:

AttributeError in /usr/lib/python3.4/asyncio/tasks.py feels like it might be a concurrency issue. I
can't reproduce it, and my python isn't good enough to know how to simulate raising the exception at a
random time during the execution of the program. Here's the PoC:

import asyncio
import sys
from asyncio import async
import time
import random
asyncio.tasks._DEBUG = True

loop = asyncio.get_event_loop()

def read_something():
  print(input())

 <at> asyncio.coroutine
def func(arg):
  while True:
    sys.stdout.write("\rtest"+str(arg))
    yield from asyncio.sleep(0)

loop.add_reader(sys.stdin, read_something)
loop.call_soon(async, func(1))
loop.call_soon(async, func(2))
loop.call_soon(async, func(3))
loop.call_soon(async, func(4))
(Continue reading)

Raymond Hettinger | 24 Apr 02:45 2014

[issue21339] IDLE crash on OS X 1.9 upon shut-down with many windows open


New submission from Raymond Hettinger:

*** Internal Error: rpc.py:SocketIO.localcall()

 Object: gui_adapter 
 Method: <bound method GUIAdapter.interaction of <idlelib.RemoteDebugger.GUIAdapter instance at
0x120e71f80>> 
 Args: ('bug.py:1: <module>()', 4350545536, None)

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/rpc.py", line
188, in localcall
    ret = method(*args, **kwargs)
  File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/RemoteDebugger.py",
line 284, in interaction
    self.gui.interaction(message, frame, modified_info)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/Debugger.py",
line 198, in interaction
    b.configure(state="disabled")
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py",
line 1262, in configure
    return self._configure('configure', cnf, kw)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py",
line 1253, in _configure
    self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
TclError: invalid command name ".4846984656.4846982712.4846983792"

----------
(Continue reading)

Thomas Kluyver | 24 Apr 01:29 2014

[issue21338] Silent mode for compileall


New submission from Thomas Kluyver:

The compileall module's command line interface has a -q (quiet) flag which suppresses most of the output,
but it still prints error messages. I'd like an entirely silent mode with no output.

My use case is byte-compiling Python files as part of a graphical installer. I do this by running:

py -${PY_QUALIFIER} -m compileall -q "$INSTDIR\pkgs"

I'd like to be able to use pyw so a terminal doesn't pop up, but if I do that, it exits early. I think this is due to
the issue with stdout/stderr buffers filling up on pythonw.

----------
components: Library (Lib)
messages: 217100
nosy: takluyver
priority: normal
severity: normal
status: open
title: Silent mode for compileall

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

(Continue reading)

Zachary Ware | 23 Apr 22:46 2014

[issue21337] Add tests for Tix


New submission from Zachary Ware:

We should have some tests for Tix, which currently has none.  The Windows buildbots will be able to run the
tests, but Tix is not guaranteed to be available elsewhere.

----------
components: Tests, Tkinter
keywords: easy
messages: 217089
nosy: zach.ware
priority: low
severity: normal
stage: needs patch
status: open
title: Add tests for Tix
type: enhancement
versions: Python 3.5

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

Ben Ma | 23 Apr 18:57 2014

[issue21336] ntpath.splitdrive fails on None argument


New submission from Ben Ma:

>>> import ntpath
>>> ntpath.splitdrive(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "E:\python3\lib\ntpath.py", line 159, in splitdrive
    if p and len(p) > 1:
TypeError: object of type 'NoneType' has no len()

Solution: (that I've found)

Lib/ntpath.py
#in function splitdrive
...
    empty = _get_empty(p)
+++ if p and len(p) > 1:
--- if len(p) > 1:
        sep = _get_sep(p)
...
            return p[:2], p[2:]
+++ else:
+++     p = ''
    return empty, p
...

----------
components: Library (Lib)
messages: 217077
(Continue reading)

Brett Cannon | 23 Apr 17:01 2014

[issue21335] Update importlib.__init__ to reset _frozen_imnportlib's loader to SourceFileLoader


New submission from Brett Cannon:

When importlib.__init__ tries to mask the fact that _frozen_importlib is frozen it should also reset
__loader__ to be an instance of SourceFileLoader. This will allow tracebacks to include source lines
thanks to SourceFileLoader.get_source().

----------
assignee: brett.cannon
components: Library (Lib)
messages: 217073
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Update importlib.__init__ to reset _frozen_imnportlib's loader to SourceFileLoader
type: behavior
versions: Python 3.5

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

randomcoder1 | 23 Apr 11:42 2014

[issue21334] nntplib throws exceptions making sinntp unusable


New submission from randomcoder1:

Sinntp is a nntp client. It uses nntplib from Python as a nntp library to fetch messages from NNTP servers.

I've tested this on two environments with the following package versions:

1) Ubuntu 12.04.4 , python-support 1.0.14ubuntu2, Python 2.7.3-0ubuntu2.2 , sinntp 1.4-1 ,
libpython2.7 2.7.3-0ubuntu3.4
2) Debian jessie , python-support 1.0.15, Python 2.7.5-5, sinntp 1.5-1 , libpython2.7 version 2.7.6-8

sinntp crashed on 2) and threw NNTP* exceptions which are described in more detail in the
bugreport-data.tgz file that comes with this  bugreport. I was also able to isolate one NNTP article that
caused it to crash, that's also included.

I've included above the libpython2.7 version because
user <at> machine:/tmp$ sudo apt-file -x search 'nntplib.py$'
[..]
libpython2.7-stdlib: /usr/lib/python2.7/nntplib.py
[..]

Upon trying to replace the sinntp 1.5-1 on 2) with the one in 1) , the problem was still present, so I believe
sinntp can be excluded.

I think the bug is caused by the newer version of libpython2.7 in 2).

----------
components: Library (Lib)
files: bureport-data.tgz
messages: 217060
(Continue reading)

Stefan Schwarzer | 23 Apr 07:57 2014

[issue21333] Document recommended exception for objects that shouldn't be pickled


New submission from Stefan Schwarzer:

I recently was confused whether to raise a `PicklingError` or `TypeError` in `__getstate__` if objects of
my class can't and shouldn't be pickled. [1]

Terry Reedy advised I should use `TypeError`. [2]

I wonder if the `pickle` module documention should explicitly recommend using `TypeError` if a class
wants to say that its objects can't be pickled. What do you think?

[1] https://mail.python.org/pipermail/python-list/2014-April/670987.html
[2] https://mail.python.org/pipermail/python-list/2014-April/671002.html

----------
assignee: docs <at> python
components: Documentation
messages: 217054
nosy: docs <at> python, sschwarzer
priority: normal
severity: normal
status: open
title: Document recommended exception for objects that shouldn't be pickled
type: enhancement
versions: Python 3.5

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


Gmane