[issue22013] Add at least minimal support for thread groups

[Raymond Hettinger]

New submission from Raymond Hettinger:

Currently, threading.Thread requires that group=None pending implementation of 
a ThreadGroup class such as that described in 
http://www.javaworld.com/article/2074481

This has been an open todo for very long time, possibly because it may be too 
big of a task to implement all the features including subgroups.

I think we can implement a small but useful set of features without too much 
difficultly:

path_explorers = threading.ThreadGroup('path_explorers')
for path in paths:
threading.Thread(path_explorers, explore, (path,))
for thread in path_explorers: # enumerate unfinished explorers
print(thread)
path_explorers.start()# begin parallel search
path_explorers.join() # wait for group to finish
print("Result:", best_path)

--
components: Library (Lib)
messages: 223498
nosy: rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Add at least minimal support for thread groups
type: enhancement
versions: Python 3.5

___
Python tracker 

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

[issue1047397] cgitb failures

[Berker Peksag]

Changes by Berker Peksag :


--
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3

___
Python tracker 

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

[issue22011] test_os extended attribute setxattr tests can fail with ENOSPC (Errno 28)

[Ned Deily]

Ned Deily added the comment:

(In the future, please just show the test failures and their tracebacks rather 
than uploading a tar file.) 

The logs show three test failures in test_os:
==
ERROR: test_fds (test.test_os.ExtendedAttributeTests)
--
Traceback (most recent call last):
  File "/home/yannick/c/src/Python-3.4.1/Lib/test/test_os.py", line 2238, in 
test_fds
self._check_xattrs(getxattr, setxattr, removexattr, listxattr)
  File "/home/yannick/c/src/Python-3.4.1/Lib/test/test_os.py", line 2213, in 
_check_xattrs
self._check_xattrs_str(str, *args, **kwargs)
  File "/home/yannick/c/src/Python-3.4.1/Lib/test/test_os.py", line 2202, in 
_check_xattrs_str
setxattr(fn, s("user.test"), b"a"*1024, **kwargs)
  File "/home/yannick/c/src/Python-3.4.1/Lib/test/test_os.py", line 2231, in 
setxattr
os.setxattr(fp.fileno(), *args)
OSError: [Errno 28] No space left on device: 4

==
ERROR: test_lpath (test.test_os.ExtendedAttributeTests)
--
Traceback (most recent call last):
  File "/home/yannick/c/src/Python-3.4.1/Lib/test/test_os.py", line 2223, in 
test_lpath
os.listxattr, follow_symlinks=False)
  File "/home/yannick/c/src/Python-3.4.1/Lib/test/test_os.py", line 2213, in 
_check_xattrs
self._check_xattrs_str(str, *args, **kwargs)
  File "/home/yannick/c/src/Python-3.4.1/Lib/test/test_os.py", line 2202, in 
_check_xattrs_str
setxattr(fn, s("user.test"), b"a"*1024, **kwargs)
OSError: [Errno 28] No space left on device: '@test_16527_tmp'

==
ERROR: test_simple (test.test_os.ExtendedAttributeTests)
--
Traceback (most recent call last):
  File "/home/yannick/c/src/Python-3.4.1/Lib/test/test_os.py", line 2219, in 
test_simple
os.listxattr)
  File "/home/yannick/c/src/Python-3.4.1/Lib/test/test_os.py", line 2213, in 
_check_xattrs
self._check_xattrs_str(str, *args, **kwargs)
  File "/home/yannick/c/src/Python-3.4.1/Lib/test/test_os.py", line 2202, in 
_check_xattrs_str
setxattr(fn, s("user.test"), b"a"*1024, **kwargs)
OSError: [Errno 28] No space left on device: '@test_16527_tmp'

--

Note that all three failures are on attempts to set a 1024-byte extended 
attributes on a /tmp file with os.setxattr(), a function which is just a 
wrapper around the Linux setxattr system call.  "man 2 setxattr" documents that 
the call can fail with ENOSPC (Errno 28) if "there is insufficient space 
remaining to store the extended attribute".  "man 5 attr", the overview of 
extended attribute support, notes that there are various kernel and file system 
specific limits on extended attributes, including length restrictions.  So 
presumably there may be legitimate reasons why these tests could get ENOSPC on 
particular system configurations.  It would be better if test_os anticipated 
such problems and passed those tests with a warning if ENOSPC is returned.

http://man7.org/linux/man-pages/man2/setxattr.2.html
http://man7.org/linux/man-pages/man5/attr.5.html

--
components: +Tests -Build
keywords: +easy
nosy: +ned.deily
stage:  -> needs patch
title: “make test” fails with 3.4.1 on Ubuntu 12.04 -> test_os extended 
attribute setxattr tests can fail with ENOSPC (Errno 28)
versions: +Python 3.5

___
Python tracker 

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

[issue17896] Move Windows external libs from \..\ to \externals

[Zachary Ware]

Zachary Ware added the comment:

After the most recent changes to the buildbot scripts, it would be every time 
without a patch to the clean script, but at the time I only meant a single time 
(which really isn't a big deal).

The patch is well out of date, I can update it if we can come to a consensus 
that this kind of change is a good idea.

--
stage:  -> patch review
versions: +Python 3.5 -Python 3.4

___
Python tracker 

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

[issue17131] subprocess.Popen.terminate can raise exception on Posix

[Martin Panter]

Martin Panter added the comment:

For Posix (dunno about Windows), calling terminate or kill at the OS level 
after a poll or wait has already succeeded is a bad idea, because the PID may 
have been recycled. It is essentially operating on a released resource, similar 
to calling “os.close” on a closed FD, or freeing unallocated memory.

There is a way to know if the PID is still valid though. Just make sure that 
successful poll and wait calls invalidate the PID. Then calling terminate or 
kill, or any other operation that requires the PID, would no longer be valid 
(or could do nothing if that is more appropriate). Similar to the behaviour of 
file objects after they are closed: subsequent close calls do nothing; other 
operations raise an exception.

--
nosy: +vadmium

___
Python tracker 

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

[issue22009] pdb.set_trace() crashes with UnicodeDecodeError when binary data is input via stdin

[Ned Deily]

Ned Deily added the comment:

The problem here is that you are trying to use sys.stdin for two different 
purposes: 1. as a data input source for your program using stdin redirected to 
a disk file; and 2. for pdb's source of debugging commands, expected to be a 
terminal file.  By specifying "-m pdb", you are telling pdb to start an 
interactive debugging which it does, paused at the first statement in sample.py 
("-> import sys, pdb").  It (actually the cmd standard library module which pdb 
uses) then tries to read stdin for command input but, because of the command 
line redirect (" < binary.exe"), reads the binary file instead.  Note this 
happens before sample.py has done anything.  If you just ran the command 
"python sample.py < binary.exe", then pdb would not be involved initially, the 
script would run, read the redirected file until EOF, and then invoke pdb via 
set_trace.  But, at that point, the redirected sys.stdin is at EOF so pdb 
immediately exits after trying to read a command.  The doc page for pdb does no
 t specifically warn against redirecting stdin but it does document that the 
pdb.Pdb instance passes stdin arguments to a cmd.Cmd instance which defaults to 
using sys.stdin.  I think that's warning enough.

There is an open pdb feature request, Issue20061, to make it more convenient to 
use pdb with a separate terminal window.  That feature would also cover the 
rare use case here of having a redirected stdin with pdb.  Otherwise, you need 
to be careful how you use stdin while using pdb.

--
components: +Library (Lib) -Windows
nosy: +ned.deily
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> 

___
Python tracker 

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

[issue1152248] Add support for reading records with arbitrary separators to the standard IO stack

[Martin Panter]

Changes by Martin Panter :


--
nosy: +vadmium

___
Python tracker 

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

[issue1927] raw_input behavior incorrect if readline not enabled

[Martin Panter]

Martin Panter added the comment:

I experimented with various redirections to /dev/null, files, and other 
terminal windows on Linux. Current behaviour I am seeing seems to be something 
like this:

* Prefers prompting to stderr if both stdout and stderr are terminals
* Prefers prompting to stdout if neither are terminals
* Prompts to the non-terminal if only one of stderr and stdout is a terminal. 
Surely this one should be the other way around if there is going to be a 
preference at all?

--
nosy: +vadmium
versions: +Python 3.4

___
Python tracker 

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

[issue1152248] Add support for reading records with arbitrary separators to the standard IO stack

[Andrew Barnert]

Andrew Barnert added the comment:

One last thing, a quick & dirty solution that works today, if you don't mind 
accessing private internals of stdlib classes, and don't mind giving up the 
performance of _io for _pyio, and don't need a solution for binary files:

class MyTextIOWrapper(_pyio.TextIOWrapper):
def readrecord(self, sep):
readnl, self._readnl = self._readnl, sep
try:
return self.readline()
finally:
self._readnl = readnl

Or, if you prefer:

class MyTextIOWrapper(_pyio.TextIOWrapper):
def __init__(self, *args, separator, **kwargs):
super().__init__(*args, **kwargs)
self._readnl = separator

For binary files, there's no solution quite as simple; you need to write your 
own readline method by copying and pasting the one from _pyio.RawIOBase, and 
the modifications to use an arbitrary separator aren't quite as trivial as they 
look at first (at least if you want multi-byte separators).

--

___
Python tracker 

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

[issue1152248] Add support for reading records with arbitrary separators to the standard IO stack

[Andrew Barnert]

Andrew Barnert added the comment:

While we're at it, Douglas Alan's solution wouldn't be an ideal solution even 
if it were a builtin. A fileLineIter obviously doesn't support the stream API. 
It means you end up with two objects that share the same file, but have 
separate buffers and out-of-sync file pointers. And it's a lot slower.

That being said, I think it may be useful enough to put in the stdlib—even more 
so if you pull the resplit-an-iterator-of-strings code out:

def resplit(strings, separator):
partialLine = None
for s in strings:
if partialLine:
partialLine += s
else:
partialLine = s
if not s:
break
lines = partialLine.split(separator)
partialLine = lines.pop()
yield from lines
if partialLine:
yield partialLine

Now, you can do this:

with open('rdm-example') as f:
chunks = iter(partial(f.read, 8192), '')
lines = resplit(chunks, '\0')
lines = (line + '\n' for line in lines)

# Or, if you're just going to strip off the newlines anyway:
with open('file-0-example') as f:
chunks = iter(partial(f.read, 8192), '')
lines = resplit(chunks, '\0')

# Or, if you have a binary file:
with open('binary-example, 'rb') as f:
chunks = iter(partial(f.read, 8192), b'')
lines = resplit(chunks, b'\0')

# Or, if I understand ysj.ray's example:
with open('ysj.ray-example') as f:
chunks = iter(partial(f.read, 8192), '')
lines = resplit(chunks, '\r\n')
records = resplit(lines, '\t')

# Or, if you have something that isn't a file at all:
lines = resplit((packet.body for packet in packets), '\n')

--

___
Python tracker 

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

[issue1152248] Add support for reading records with arbitrary separators to the standard IO stack

[Andrew Barnert]

Andrew Barnert added the comment:

http://thread.gmane.org/gmane.comp.python.ideas/28310 discusses the same idea.

Guido raised a serious problem with either adding an argument to readline and 
friends, or adding new methods readrecord and friends: It means the hundreds of 
existing file-like objects that exist today no longer meet the file API.

Putting the separator in the constructor call solves that problem. Construction 
is not part of the file API, and different file-like objects' constructors are 
already wildly different. It also seems to fit in better with what perl, awk, 
bash, etc. do (whether you either set something globally, or on the file, 
rather than on the line-reading mechanism). And it seems conceptually cleaner; 
a file shouldn't be changing line-endings in mid-stream—and if it does, that's 
similar to changing encodings.

Whether this should be done by reusing newline, or by adding another new 
parameter, I'm not sure. The biggest issue with reusing newline is that it has 
a meaning for write mode, not just for read mode (either terminal \n 
characters, or all \n characters, it's not entire clear which, are replaced 
with newline), and I'm not sure that's appropriate here. (Or, worse, maybe it's 
appropriate for text files but not binary files?)

R. David Murray's patch doesn't handle binary files, or _pyio, and IIRC from 
testing the same thing there was one more problem to fix for text files as 
well… but it's not hard to complete. If I have enough free time tomorrow, I'll 
clean up what I have and post it.

--
nosy: +abarnert

___
Python tracker 

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

[issue15305] Test harness unnecessarily disambiguating twice

[Mark Lawrence]

Mark Lawrence added the comment:

The patch is very short so can we have a formal review please.

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue17210] documentation of PyUnicode_Format() states wrong argument type requirements

[Roundup Robot]

Roundup Robot added the comment:

New changeset 9cd3ab7c09d1 by Benjamin Peterson in branch '2.7':
args doesn't need to be a tuple (closes #17210)
http://hg.python.org/cpython/rev/9cd3ab7c09d1

New changeset ffbbd43d7342 by Benjamin Peterson in branch '3.4':
args doesn't need to be a tuple (closes #17210)
http://hg.python.org/cpython/rev/ffbbd43d7342

New changeset 2fc379ce5762 by Benjamin Peterson in branch 'default':
merge 3.4 (#17210)
http://hg.python.org/cpython/rev/2fc379ce5762

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue22012] struct.unpack('?', '\x02') returns (False, ) when Python is built with clang

[Ned Deily]

Changes by Ned Deily :


--
title: struct.unpack('?', '\x02') returns (False,) on Mac OSX -> 
struct.unpack('?', '\x02') returns (False,) when Python is built with clang

___
Python tracker 

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

[issue22012] struct.unpack('?', '\x02') returns (False,) on Mac OSX

[Ned Deily]

Ned Deily added the comment:

FTR, the problem also shows up with the current clang-3.4 (3.4.2) and clang3.5 
(svn213451-1) packages in Debian testing (on i386), building --with-pydebug and 
without, so the issue is not confined to OS X.

--
assignee: ronaldoussoren -> 

___
Python tracker 

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

[issue22012] struct.unpack('?', '\x02') returns (False,) on Mac OSX

[Ned Deily]

Changes by Ned Deily :


--
components: +Build -Macintosh

___
Python tracker 

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

[issue15106] Potential Bug in errors.c

[Mark Lawrence]

Mark Lawrence added the comment:

>From what I can see the code is completely the same in default but does this 
>matter or not?  As a matter of interest is there an official policy regarding 
>code clones, whether in C or pure Python?

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue7676] IDLE shell shouldn't use TABs

[Terry J. Reedy]

Terry J. Reedy added the comment:

The problem with just /\t// is the absence of a secondary prompt.

>>> def f():
return 'not acceptible'

Hence the 8+4+4... proposal. With a proportional font, the return would start 
to the *left* of def. Adding '... ' works for fixed pitch fonts, but '...' is 
much narrower than '>>>' in a proportional font.

The problem with mandating 'fixed pitch' is that unicode fonts, such as Lucida 
Sans Unicode on Windows, are proportional.  With that font, spaces are very 
narrow: '8+4' would need to be 13 + 4 + 4 ... to look right, *on Idle*.  I feel 
that continuing to work with proportional fonts, for code not limited to ascii, 
is more important than this issue.

To look right regardless of font, code should start at the margin, with prompts 
in a separate narrow window. This means that output would not be dedented under 
input prompts.
---
 in> def f():
 print('code against margin')

out> code against margin
---
' in> ' and 'out> ' (or whatever input and output indicators were used) would 
be in a vertical strip (like line numbers) with, say, a light gray background 
(such as used here).  Normal output would be, say, the current blue on a very 
light blue background. Similarly for red stderr output. It takes very little 
tint to be distinct from a white background. I have set my custom configuration 
to try this out.

Cutting code is a different issue. As I said above, I think custom functions 
are needed. One could only cut code. Another could add '>>> ' and '... ' before 
input lines, for pasting into docstrings. Another could add '# ' before output 
lines, for pasting into messages in a form that readers could recut and paste 
into an editor.

--

___
Python tracker 

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

[issue17896] Move Windows external libs from \..\ to \externals

[Mark Lawrence]

Mark Lawrence added the comment:

I also find the location annoying and would be happy to see it moved.

Regarding the "extra long build time on the buildbots due to having to 
recompile Tcl/Tk and OpenSSL" is this a one off the first time you run after 
the commit, or does it always happen because the buildbots run some form of 
clean?  Sorry if this sounds like a daft question but I haven't the faintest 
idea how the various buildbots are configured.

--
nosy: +BreamoreBoy, steve.dower, terry.reedy

___
Python tracker 

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

[issue17896] Move Windows external libs from \..\ to \externals

[Brian Curtin]

Changes by Brian Curtin :


--
nosy:  -brian.curtin

___
Python tracker 

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

[issue9399] Provide a 'print' action for argparse

[paul j3]

paul j3 added the comment:

As Steven notes, the patch lacks tests.  It also lacks documentation.  

The 2 things that this class does different from 'version' are
- write without passing the text through 'textwrap'
- write to a user defined file

There is a difference in opinion between Éric and Steven as to whether the 
class should use write directly or use the HelpFormatter.

I don't think it needs further action at this time.  There doesn't seem to be a 
lot of interest in it.  Also there are a number of ways of accomplishing the 
task without adding an Action class.

- the class is a simple adaptation of the 'version' class

- a user defined class works just as well

- 'version' with Raw formatter, and shell redirection also works

- it is also easy to write the text to a file after parse_args.

I've attached a file that illustrates a number of these alternatives.  It 
includes a 'callable' class.
-

The discussion got me thinking about a selective version of the RAW formatting, 
analogous to the HTML  tag.  With this the user could mark a given text 
(description, epilog, help, version etc) as pre-formatted, without having to 
change the formatter_class.

parser.add_argument('--license', action='version',
version=Pre(formatted_text))

I probably should submit that in a new issue.

--
Added file: http://bugs.python.org/file35997/try_write.py

___
Python tracker 

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

[issue21997] Pdb.set_trace debugging does not end correctly

[Terry J. Reedy]

Terry J. Reedy added the comment:

With Python 3.4.1, Win 7, there is a detour stepping through displayhook before 
arriving at the same place with the same result upon quitting. If one does not 
quit, stepping ends at

> c:\programs\python34\lib\threading.py(235)__enter__()
-> return self._lock.__enter__()
(Pdb) s
--Return--
s 
---

With respect to b, the exception, this seems to be a duplicate, and I am 
inclined to close this issue as such.

With respect to a, not stopping, this is not a bug, at least not one involving 
Idle. Idle executes code within an exec call within a call of the runcode 
method of the Executive class. In a similar circumstance, the console 
interpreter does not stop either. So I have removed Idle from the title and 
components.

A direct exec is semi-problemmatical. 

>>> import pdb
>>> def do(): pdb.set_trace()
...
>>> exec('do()', locals())
--Return--
> (1)do()->None
(Pdb) s
--Return--
> (1)()->None
(Pdb) s
--Return--
> (1)()->None
(Pdb) s

# This returns to a '>>>' prompt,

>>> def run(): exec('do()', locals())

# but hitting  after this line returns us to the debugger.

--Call--
> c:\programs\python34\lib\encodings\cp437.py(14)decode()
-> def decode(self,input,errors='strict'):
(Pdb)
> c:\programs\python34\lib\encodings\cp437.py(15)decode()
-> return codecs.charmap_decode(input,errors,decoding_table)
(Pdb) q
  File "", line 0

^
SyntaxError: decoding with 'cp437' codec failed (BdbQuit: )

# Now we are really out.

>>> run()
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'run' is not defined

# the def statement did not execute

>>> def run(): exec('do()', globals())
...
>>> run()

# and now the behavior is as reported for Idle

--Return--
> (1)do()->None
s

# about 20 steps later, still going.

s
> c:\programs\python34\lib\encodings\cp437.py(19)encode()
-> return codecs.charmap_encode(input,self.errors,encoding_map)[0]
-

I know very little about the pdb spec and do not know whether the above is a(n 
unreported) python or pdb bug or not. If any of you think it is, say so. 
Otherwise this should be closed.

--
components:  -IDLE
stage:  -> resolved
superseder:  -> pdb raises BdbQuit on 'quit' when started with set_trace
title: Pdb.set_trace debugging does not end correctly in IDLE -> Pdb.set_trace 
debugging does not end correctly
versions: +Python 3.4, Python 3.5

___
Python tracker 

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

[issue22012] struct.unpack('?', '\x02') returns (False,) on Mac OSX

[Mark Dickinson]

Mark Dickinson added the comment:

> Some debugging shows that we're calling 'nu_bool' even for " a bit odd.

Ah, I see.  There's an optimisation that uses the native table functions 
instead of the big/little-endian ones if the size and byte order match.

--

___
Python tracker 

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

[issue16446] pdb raises BdbQuit on 'quit' when started with set_trace

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
versions: +Python 3.5 -Python 3.2, Python 3.3

___
Python tracker 

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

[issue22012] struct.unpack('?', '\x02') returns (False,) on Mac OSX

[Mark Dickinson]

Mark Dickinson added the comment:

The relevant piece of code in the struct module looks like this:

static PyObject *
nu_bool(const char *p, const formatdef *f)
{
BOOL_TYPE x;
memcpy((char *)&x, p, sizeof x);
return PyBool_FromLong(x != 0);
}

Is it possible that BOOL_TYPE is a bitfield of length 1, and that clang is 
somehow making use of that fact?

One thing I don't understand is that this shouldn't affect *standard* packing 
and unpacking (as opposed to native), but I still see the problem for a format 
of "".  Some debugging shows that we're 
calling 'nu_bool' even for "

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

[issue21996] gettarinfo method does not handle files without text string names

[R. David Murray]

R. David Murray added the comment:

Agreed, the documentation should be modified to say "(using os.fstat on its 
file descriptor, and its 'name' attribute if arcname is not specified").

--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python, r.david.murray
stage:  -> needs patch
versions: +Python 2.7

___
Python tracker 

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

[issue22006] thread module documentation erroneously(?) states not all built-in functions that do blocking I/O release the GIL

[Mark Dickinson]

Mark Dickinson added the comment:

It's gone.

--
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions:  -Python 3.3

___
Python tracker 

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

[issue22006] thread module documentation erroneously(?) states not all built-in functions that do blocking I/O release the GIL

[Roundup Robot]

Roundup Robot added the comment:

New changeset 855ff9182a07 by Mark Dickinson in branch '3.4':
Issue #22006: Remove outdated _thread caveat.  Thanks Dan O'Reilly for the 
report.
http://hg.python.org/cpython/rev/855ff9182a07

New changeset 3b6b905ae229 by Mark Dickinson in branch 'default':
Issue #22006: Merge from 3.4.
http://hg.python.org/cpython/rev/3b6b905ae229

--
nosy: +python-dev

___
Python tracker 

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

[issue22006] thread module documentation erroneously(?) states not all built-in functions that do blocking I/O release the GIL

[Roundup Robot]

Roundup Robot added the comment:

New changeset 4f359c631bb0 by Mark Dickinson in branch '2.7':
Issue #22006: Remove outdated thread module caveat.  Thanks Dan O'Reilly for 
the report.
http://hg.python.org/cpython/rev/4f359c631bb0

--

___
Python tracker 

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

[issue17667] Windows: build with "build_pgo.bat -2" fails to optimize python.dll

[Brian Curtin]

Changes by Brian Curtin :


--
nosy:  -brian.curtin

___
Python tracker 

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

[issue17709] http://docs.python.org/2.7/objects.inv doesn't support :func:`repr` or :exc:`Exception`

[Mark Lawrence]

Mark Lawrence added the comment:

I don't understand this at all, but if this is a Sphinx bug shouldn't it be 
reported on the appropriate bug tracker and not here?

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue17667] Windows: build with "build_pgo.bat -2" fails to optimize python.dll

[Mark Lawrence]

Mark Lawrence added the comment:

See also #21907.

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue21907] Update Windows build batch scripts

[Mark Lawrence]

Mark Lawrence added the comment:

Does this render the patch against build_pgo.bat on #17667 obsolete?

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue22012] struct.unpack('?', '\x02') returns (False,) on Mac OSX

[Ned Deily]

Ned Deily added the comment:

Doing a quick look, the results vary.  Using current python.org 2.7.8 and 3.4.1 
installers, the results are correct.  These interpreters are built with Apple 
gcc-4.2 (non-LLVM) from Xcode 3.2.6.  Other 2.7 and 3.4.x builds I have 
available at the moment, including the Apple-supplied Python 2.7, were built 
with clang LLVM and they all give the incorrect result.
  
$ /usr/bin/python2.7 -c "import sys,struct;print(struct.unpack('', 
b'\x00\x01\x02\x03'), sys.version)"
((False, True, False, True), '2.7.5 (default, Mar  9 2014, 22:15:05) \n[GCC 
4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)]')

$ arch -i386 /usr/bin/python2.7 -c "import 
sys,struct;print(struct.unpack('', b'\x00\x01\x02\x03'), sys.version)"
((False, True, False, True), '2.7.5 (default, Mar  9 2014, 22:15:05) \n[GCC 
4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)]')

$ /usr/local/bin/python2.7 -c "import sys,struct;print(struct.unpack('', 
b'\x00\x01\x02\x03'), sys.version)"
((False, True, True, True), '2.7.8 (v2.7.8:ee879c0ffa11, Jun 29 2014, 21:07:35) 
\n[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]')

$ /usr/local/bin/python2.7-32 -c "import sys,struct;print(struct.unpack('', 
b'\x00\x01\x02\x03'), sys.version)"
((False, True, True, True), '2.7.8 (v2.7.8:ee879c0ffa11, Jun 29 2014, 21:07:35) 
\n[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]')

$ /usr/local/bin/python3.4 -c "import sys,struct;print(struct.unpack('', 
b'\x00\x01\x02\x03'), sys.version)"
(False, True, True, True) 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 00:54:21)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]

$ /usr/local/bin/python3.4-32 -c "import sys,struct;print(struct.unpack('', 
b'\x00\x01\x02\x03'), sys.version)"
(False, True, True, True) 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 00:54:21)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]

$ ./bin/python3.4 -c "import sys,struct;print(struct.unpack('', 
b'\x00\x01\x02\x03'), sys.version)"
(False, True, False, True) 3.4.1+ (3.4:d6b71971b228, Jul 16 2014, 16:30:56)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)]

--
nosy: +ned.deily
versions:  -Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

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

[issue22006] thread module documentation erroneously(?) states not all built-in functions that do blocking I/O release the GIL

[Guido van Rossum]

Guido van Rossum added the comment:

Not in my wildest dreams could I have expected that that claim would still be 
in the docs 20 years later. :-)  Please get rid of it.

--

___
Python tracker 

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

[issue22012] struct.unpack('?', '\x02') returns (False,) on Mac OSX

[Tyler Wade]

New submission from Tyler Wade:

On Mac OSX, struct.unpack incorrectly handles bools.

Python 3.4.1 (default, May 19 2014, 13:10:29)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.unpack('', b'\x00\x01\x02\x03')
(False, True, False, True)

--
assignee: ronaldoussoren
components: Macintosh
messages: 223470
nosy: ronaldoussoren, wayedt
priority: normal
severity: normal
status: open
title: struct.unpack('?', '\x02') returns (False,) on Mac OSX
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

___
Python tracker 

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

[issue22007] sys.stdout.write on OS X is not EINTR safe

[STINNER Victor]

STINNER Victor added the comment:

> I can reproduce the issue on Linux:

Sorry, I forgot to mention that I reproduced the issue on Fedora 20 with Python 
2.7.

I cannot reproduce with Python 3.3.

--

___
Python tracker 

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

[issue22011] “make test” fails with 3.4.1 on Ubuntu 12.04

[Yannick Duchêne]

New submission from Yannick Duchêne:

`make test` fails with Python 3.4.1 on Ubuntu 12.04 Intel 32 bits.

The single `./configure` option used, was `--prefix=$HOME/.local`.

As attached file, an archive containing both standard output and standard error 
outputs.

Not some important error notifications appears only in standard output, not in 
standard error: “OSError: [Errno 28] No space left on device”.

The latter is surprising as there was 11GiB free space.

--
components: Build
files: test-logs.tar.gz
messages: 223468
nosy: Hibou57
priority: normal
severity: normal
status: open
title: “make test” fails with 3.4.1 on Ubuntu 12.04
versions: Python 3.4
Added file: http://bugs.python.org/file35996/test-logs.tar.gz

___
Python tracker 

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

[issue7676] IDLE shell shouldn't use TABs

[Stephen Paul Chappell]

Stephen Paul Chappell added the comment:

If you want the IDLE shell to be as consistent as possible with the editor 
windows, changing the TAB binding to insert four spaces instead of a tab 
(alternative 2) would be helpful.

--

___
Python tracker 

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

[issue17528] Implement dumps/loads for lru_cache

[Antoine Pitrou]

Antoine Pitrou added the comment:

That doesn't sound like a good idea. lru_cache is a decorator, that acts as 
transparently as possible (i.e. the decorated function has the same metadata 
and appearance as the original function). Therefore, the lru_cache'd function 
should also pickle as a regular function - which it currently does.

Having a pickle carry all the cache overhead would actually be a regression - 
instead of a couple of bytes representing the function's global name, you could 
now get kilobytes (or more) of data representing the whole cache contents.
(and, also, it would fail if the cache contains any non-picklable data)

--
nosy: +pitrou

___
Python tracker 

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

[issue22006] thread module documentation erroneously(?) states not all built-in functions that do blocking I/O release the GIL

[Antoine Pitrou]

Antoine Pitrou added the comment:

It all depends what you call "I/O". What is true is that not all functions 
doing system calls release the GIL, AFAIR. If you mean I/O as in actual disk or 
network I/O then yes, all such functions whould release the GIL.

That said, I agree that the statement isn't very helpful.

--
nosy: +pitrou

___
Python tracker 

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

[issue1047397] cgitb failures

[Robin Becker]

Robin Becker added the comment:

I'll repeat the post I made to BreamoreBoy regarding this bug:

"re: http://bugs.python.org/issue1047397

this bug is now 10 years old. I'm not sure why it's to be considered
closed because the original intent of the bug report was that the html
output of the cgitb module could be confused and errors during
evaluation could make the html output fail. So far as I can tell by
modifying the original cgitbbug.py to run under python 3.4.1 it still
fails to correctly produce html when a bug occurs in cgitb.html.
Producing a more reasonable traceback is certainly a step forward, but
I think that has been true since at least 3.1. The whole point of
cgitb is to produce something reasonable for an html consumer."

I have re-created the original 002 patch with mods for python 3.4.1. It's a bit 
of a shame that this wasn't fixed 10 years ago. Hopefully any style pedants 
will find this patch more acceptable. Personally I don't think style errors 
should prevent a working fix from being adopted. I would have just fixed the 
fix style and carped afterwards.

--
Added file: http://bugs.python.org/file35995/bugfix003.patch

___
Python tracker 

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

[issue21997] Pdb.set_trace debugging does not end correctly in IDLE

[Xavier de Gaye]

Xavier de Gaye added the comment:

Two issues here:
a) in IDLE, on a 'return' debug event in the main module, the step command does 
not end the debugging session.
b) in IDLE, BdbQuit is raised by the quit command when the debugger is started 
with pdb.set_trace().

I do not know IDLE, but a) seems closely related to issue 14743: "on 
terminating, Pdb debugs itself".

As for b) BdbQuit is also raised outside of IDLE (see also issue 16446: "pdb 
raises BdbQuit on 'quit' when started with set_trace"):

>>> def dodebug():
...   import pdb; pdb.set_trace()
... 
>>> dodebug()
--Return--
> (2)dodebug()->None
(Pdb) quit
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in dodebug
  File "/usr/local/lib/python3.5/bdb.py", line 52, in trace_dispatch
return self.dispatch_return(frame, arg)
  File "/usr/local/lib/python3.5/bdb.py", line 96, in dispatch_return
if self.quitting: raise BdbQuit
bdb.BdbQuit

--
nosy: +xdegaye

___
Python tracker 

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

[issue21964] inconsistency in list-generator comprehension with yield(-from)

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
versions:  -Python 3.2, Python 3.3

___
Python tracker 

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

[issue21964] inconsistency in list-generator comprehension with yield(-from)

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
stage:  -> test needed

___
Python tracker 

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

[issue22006] thread module documentation erroneously(?) states not all built-in functions that do blocking I/O release the GIL

[Mark Dickinson]

Changes by Mark Dickinson :


--
stage:  -> needs patch

___
Python tracker 

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

[issue22006] thread module documentation erroneously(?) states not all built-in functions that do blocking I/O release the GIL

[Mark Dickinson]

Mark Dickinson added the comment:

It seems likely that this information is just out of date.  But even if there 
*are* still built-in functions lurking somewhere that don't release the GIL 
during I/O, the statement in the docs isn't really helpful in finding them.  
Either way, I'd recommend simply removing it.

Adding Guido to the nosy in case he can provide a pre-Python 1.0 historical 
perspective.

--
nosy: +gvanrossum, mark.dickinson
versions:  -Python 3.1, Python 3.2

___
Python tracker 

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