[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Trent Nelson]

Changes by Trent Nelson :


--
stage: needs patch -> patch review

___
Python tracker 

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

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Trent Nelson]

New submission from Trent Nelson:

This is somewhat related to Issue #9860.  You can't currently build Python 
out-of-tree when the source directory is readonly.  This is because there are a 
few Parser/pgen/AST/python_asdl.py steps that try and write to $(srcdir).

The attached patch fixes this.

--
assignee: trent
files: readonly_src.patch
keywords: patch
messages: 169430
nosy: trent
priority: low
severity: normal
stage: needs patch
status: open
title: Unable to build Python out-of-tree when source tree is readonly.
type: compile error
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27054/readonly_src.patch

___
Python tracker 

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

[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed

[Ross Lagerwall]

Ross Lagerwall added the comment:

I sent a review through on rietveld; I'm attaching a patch with the changes so 
that it compiles and passes the tests.

--
Added file: http://bugs.python.org/file27053/issue15798_v2.patch

___
Python tracker 

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

[issue15765] test_getcwd_long_pathnames (in test_posix) kills NetBSD

[Trent Nelson]

Changes by Trent Nelson :


--
status: open -> closed

___
Python tracker 

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

[issue15818] multiprocessing documentation of Process.exitcode

[Josh Kupershmidt]

New submission from Josh Kupershmidt:

[I tried to send this as an email to d...@python.org yesterday, but it seems to 
have gotten eaten, as I don't see the message in the archives.]

Hi all,

The documentation for the multiprocessing module claims:

| Note that the start(), join(), is_alive() and exit_code methods
| should only be called by the process that created the process object.

Two problems with this description:
 1. "exit_code" should be spelled "exitcode"
 2. exitcode is an attribute of the Process class, not a method as
claimed, since the underlying method is decorated with @property

Also, aside from the above documentation issues, if it is true that
it's not safe to query the exitcode from a separate process, should
the exitcode property method include a check like so:

assert self._parent_pid == os.getpid(), 'can only test a child process'

since start(), join(), and is_alive() all perform this check?

--
assignee: docs@python
components: Documentation
messages: 169428
nosy: docs@python, schmiddy
priority: normal
severity: normal
status: open
title: multiprocessing documentation of Process.exitcode
versions: Python 2.7, Python 3.3

___
Python tracker 

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

[issue13405] Add DTrace probes

[Jesús Cea Avión]

Jesús Cea Avión added the comment:

OpenIndiana custom buildbots, 32 and 64 bits, SUCCESFULL:

2.7 branch:

32 bits:
http://buildbot.python.org/all/builders/x86%20OpenIndiana%20custom/builds/6

64 bits:
http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%20custom/builds/8

3.3 branch:

32 bits:
http://buildbot.python.org/all/builders/x86%20OpenIndiana%20custom/builds/7

64 bits:
http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%20custom/builds/9

Waiting for Solaris 11 custom buildbot to come online again :)

--

___
Python tracker 

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

[issue15808] Possibility of setting custom key bindings for "Additional help sources" menu items

[Ned Deily]

Changes by Ned Deily :


Added file: http://bugs.python.org/file27052/issue15808_idle_doc_paths.patch

___
Python tracker 

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

[issue15808] Possibility of setting custom key bindings for "Additional help sources" menu items

[Ned Deily]

Changes by Ned Deily :


Removed file: http://bugs.python.org/file27051/issue15808_idle_doc_paths.patch

___
Python tracker 

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

[issue15808] Possibility of setting custom key bindings for "Additional help sources" menu items

[Ned Deily]

Ned Deily added the comment:

Here's a patch to update the doc paths to include current ones for 
Debian/Ubuntu and Fedora.  The patch will have to be tweaked a bit for 3.2/2.7 
to change sys.base_prefix to sys.prefix.

--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file27051/issue15808_idle_doc_paths.patch

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Nick Coghlan]

Nick Coghlan added the comment:

My perspective is that hashing a memoryview only makes sense when the 
memoryview is read-only and "m == m.tobytes()" (i.e. it's a C contiguous 1D 
view of bytes, either because that's what the original object exported as a 
buffer or because the view has been cast that way)

So, I think we should document that restriction in What's New and the 
memoryview docs for 3.3.0, and actually enforce it in 3.3.1 by raising 
ValueError from hash(m) when the assumption of a 1D C contiguous bytes view is 
violated (the "read-only" restriction is already enforced).

In previous versions, this constraint didn't need to be explicitly enforced, 
since memoryview basically treated *everything* as a 1D C contiguous view of 
bytes.

--

___
Python tracker 

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

[issue15805] Add stdout redirection tool to contextlib

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
nosy: +belopolsky

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
nosy: +belopolsky

___
Python tracker 

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

[issue15817] Misc/gdbinit: Expose command documentation to gdb help

[Alexander Belopolsky]

New submission from Alexander Belopolsky:

Currently "help user-defined" lists commands defined in Misc/gdbinit without 
explanations


(gdb) help user-defined
User-defined commands.
The commands in this class are those defined by the user.
Use the "define" command to define a command.

List of commands:

lineno -- User-defined
printframe -- User-defined
pu -- User-defined
pyframe -- User-defined
pyframev -- User-defined
pyg -- User-defined

With attached patch, you get


List of commands:

lineno -- User-defined
printframe -- User-defined
pu -- Generally useful macro to print a Unicode string
pyframe -- User-defined
pyframev -- Print the current frame - verbose
pyg -- Prints a representation of the object to stderr
pylocals -- Print the local variables of the current frame
pyo -- Prints a representation of the object to stderr
pystack -- Print the entire Python call stack
pystackv -- Print the entire Python call stack - verbose mode

This should be further polished, but I wanted to hear from others before 
spending more effort.

--
components: Demos and Tools
files: gdbinit.diff
keywords: patch
messages: 169424
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Misc/gdbinit: Expose command documentation to gdb help
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27050/gdbinit.diff

___
Python tracker 

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

[issue15781] test_threaded_import fails with -j4

[Antoine Pitrou]

Antoine Pitrou added the comment:

Looks fixed!

--
resolution:  -> fixed
stage: commit 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

[issue15800] Closing of sys.std* files in gzip test.

[Antoine Pitrou]

Antoine Pitrou added the comment:

A simple fix indeed, thank you.

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

[issue15800] Closing of sys.std* files in gzip test.

[Roundup Robot]

Roundup Robot added the comment:

New changeset 0b5ba5f610a9 by Antoine Pitrou in branch '3.2':
Issue #15800: fix the closing of input / output files when gzip is used as a 
script.
http://hg.python.org/cpython/rev/0b5ba5f610a9

New changeset be505d22dde8 by Antoine Pitrou in branch 'default':
Issue #15800: fix the closing of input / output files when gzip is used as a 
script.
http://hg.python.org/cpython/rev/be505d22dde8

--
nosy: +python-dev

___
Python tracker 

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

[issue15815] Add numerator to ZeroDivisionError messages

[Antoine Pitrou]

Antoine Pitrou added the comment:

> In case the value of the numerator helps find out why the denominator
> is 0. The example given by Mike Graham on python-ideas, Verbose
> traceback formatting was
> 
> def f(a):
> x = a * 4
> y = a - 4
> return x / y

Well, in this case y == 0 iff a == 4. I don't see how the numerator
helps at all.
(and besides, it's a rather silly artificial example)

--

___
Python tracker 

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

[issue15815] Add numerator to ZeroDivisionError messages

[Terry J. Reedy]

Terry J. Reedy added the comment:

In case the value of the numerator helps find out why the denominator is 0. The 
example given by Mike Graham on python-ideas, Verbose traceback formatting was

def f(a):
x = a * 4
y = a - 4
return x / y

--

___
Python tracker 

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

[issue15815] Add numerator to ZeroDivisionError messages

[Antoine Pitrou]

Antoine Pitrou added the comment:

What would be the point? Usually you should find out why the denominator is 
zero, not what the numerator's value is.

--
nosy: +pitrou

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Martin v . Löwis]

Martin v. Löwis added the comment:

Am 29.08.12 22:04, schrieb Stefan Krah:
> In the memoryview-hash thread on python-dev [1] this objection was
> addressed by demanding from exporters that they all use:
>
> hash(x) == hash(x.tobytes())
>
> Since the previous equality concept was also based on
> x.tobytes() == y.tobytes(), this wasn't a problem.

In the light of this requirement, it's even more difficult to ask
people that they change their hashing, since some exporters may already
comply with that original request.

> The new equality definition and any possible new hash definition should
> probably also be part of the buffer API documentation, since they
> aren't memoryview specific.

That's not true: they *are* memoryview-specific. The notion of equality
is entirely one of memoryview objects, not of buffers.

I still maintain that specifying hashing for memoryviews under the
new equality definition is just not feasible, and that we should give
up on it (except perhaps supporting the hashing of bytes views).
I also question whether it is useful to hash arbitrarily-shaped
read-only buffers (along with questioning whether people will actually
*have* arbitrarily-shaped read-only buffers).

Stefan: please do propose a semantics also along with proposing interfaces.

--

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Stefan Krah]

Stefan Krah added the comment:

And since memory_richcompare() and any potentially compatible hash function
are quite tricky to implement by now, perhaps the generally useful parts
could be exposed as PyBuffer_RichCompareBool() and PyBuffer_Hash().

--

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Stefan Krah]

Stefan Krah added the comment:

Martin v. L??wis  wrote:
> In general, since memoryview(obj)==obj, it would be necessary that
> hash(memoryview(obj))==hash(obj). However, since memoryview cannot
> know what hashing algorithm obj uses, it cannot compute the hash
> value with the same algorithm.

In the memoryview-hash thread on python-dev [1] this objection was
addressed by demanding from exporters that they all use:

   hash(x) == hash(x.tobytes())

Since the previous equality concept was also based on
x.tobytes() == y.tobytes(), this wasn't a problem.

The new equality definition and any possible new hash definition should
probably also be part of the buffer API documentation, since they
aren't memoryview specific.

[1] http://mail.python.org/pipermail/python-dev/2011-November/114459.html

--

___
Python tracker 

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

[issue15808] Possibility of setting custom key bindings for "Additional help sources" menu items

[Ned Deily]

Ned Deily added the comment:

Actually, IDLE does have code to look for an on-disk copy of the html-formatted 
Python documentation set but the paths are platform-specific and, in the Linux 
case, are out-of-date for some distributions at least.  For Linux platforms it 
looks for `index.html` in either `/var/www/html/python` or 
`/usr/share/doc/python-docs-x.y/Doc/`.  On current Debian systems, for example, 
the Python doc package is installed in `/usr/share/doc/pythonx.y-doc/html`.  If 
you install the doc packages and then create a link, IDLE should find the docs 
off-line when you select `Python Docs` from the `Help` manual.  For example, 
for Python 3.3 you *could* do:

sudo aptitude install python3.3-doc
sudo mkdir -p /var/www/html/
sudo ln -s /usr/share/doc/python3.3-doc/html python

That said, the default locations should be updated. And perhaps a more useful 
customization would be to add a user configuration option for where to look for 
the on-disk copy of the docs rather than adding another hot key. (Also, older 
versions of Python are in security fix mode only.)

--
nosy: +ned.deily
stage:  -> needs patch
versions:  -Python 2.6, Python 3.1

___
Python tracker 

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

[issue14803] Add feature to allow code execution prior to __main__ invocation

[Andrew Svetlov]

Changes by Andrew Svetlov :


--
nosy: +asvetlov

___
Python tracker 

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

[issue15816] pydoc.py uses a hack that depends on implementation details and breaks help() when __builtin__.__import__ is overwritten.

[R. David Murray]

R. David Murray added the comment:

Replacing __import__ is not supported.

That said, this is fixed in 3.3.

--
nosy: +r.david.murray
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue15816] pydoc.py uses a hack that depends on implementation details and breaks help() when __builtin__.__import__ is overwritten.

[David Kreuter]

New submission from David Kreuter:

help("compile") # this works
import __builtin__
real_import = __import__
__builtin__.__import__ = lambda *a: real_import(*a)
help("compile") # this fails

The line responsible for this is in pydoc.py around line 300:
... elif exc is ImportError and extract_tb(tb)[-1][2]=='safeimport': ...

--
components: Library (Lib)
messages: 169412
nosy: dkreuter
priority: normal
severity: normal
status: open
title: pydoc.py uses a hack that depends on implementation details and breaks 
help() when __builtin__.__import__ is overwritten.
versions: Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Martin v . Löwis]

Martin v. Löwis added the comment:

Am 29.08.12 21:06, schrieb Antoine Pitrou:
>> So what specific hash algorithm do you propose?
>
> The current algorithm works well in conjunction with bytes objects.

That's about the only type if works for.

>> My claim is that any hash definition for memoryviews will have a
>> *fundamental* flaw, failing to provide the basic property
>> that A==B must imply hash(A)==hash(B), making it actually work
>> incorrectly
>
> Why is there such a fundamental flaw?

The current algorithm is flawed as described in Stefan's original
message: two objects compare equal, yet hash different. That means
that if you use them as dictionary keys, you may end up with two
different values for the "same" key, depending on the size of the
dictionary (as the modulo operation in the dictionary still may
map the different hashes to the same dictionary slot).

In general, since memoryview(obj)==obj, it would be necessary that
hash(memoryview(obj))==hash(obj). However, since memoryview cannot
know what hashing algorithm obj uses, it cannot compute the hash
value with the same algorithm.

IOW, hashing is mutually exclusive with comparison with the
underlying object, unless you know what the hash algorithm
of the underlying object is.

So restricting tp_hash to memoryview objects where the underlying
object is the bytes type would work.

--

___
Python tracker 

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

[issue15815] Add numerator to ZeroDivisionError messages

[Terry J. Reedy]

New submission from Terry J. Reedy:

I propose that we add 'of ' to all ZeroDivisionError messagesso it is less 
necessary to use a debugger to add print statements to recover the information 
currently tossed away. (I also propose to change denominator from 'zero' to 
'0', '0.0', '0+0j', as appropriate.) 

>>> 3//0
...
ZeroDivisionError: integer division or modulo by zero

# augment to
ZeroDivisionError: integer division or modulo of 3 by 0

Similarly for

>>> 3 / 0
ZeroDivisionError: division by zero

# perhaps this should be 'true division of 3 by 0'

>>> 3.0 / 0.0
ZeroDivisionError: float division by zero

>>> (3+3j) / (0+0j)
ZeroDivisionError: complex division by zero

In #7482 it was proposed to make float and complex messages same as int message 
by adding 'or modulo'. I an not sure why not to do that, or if it was just 
deferred.

Fractions currently print the numerator as part of an invalid numerator / 0 
result from *either* construction or division.

>>> from fractions import Fraction as F
>>> F(3, 0)
Traceback (most recent call last):
  File "", line 1, in 
F(3, 0)
  File "C:\Programs\Python33\lib\fractions.py", line 167, in __new__
raise ZeroDivisionError('Fraction(%s, 0)' % numerator)
ZeroDivisionError: Fraction(3, 0)

# Here, 'Fraction(3, 0)' is invalid input.

>>> F(3, 1) / F(0, 1)
Traceback (most recent call last):
  File "", line 1, in 
F(3, 1) / F(0, 1)
  File "C:\Programs\Python33\lib\fractions.py", line 367, in forward
return monomorphic_operator(a, b)
  File "C:\Programs\Python33\lib\fractions.py", line 417, in _div
a.denominator * b.numerator)
  File "C:\Programs\Python33\lib\fractions.py", line 167, in __new__
raise ZeroDivisionError('Fraction(%s, 0)' % numerator)
ZeroDivisionError: Fraction(3, 0)

# Here, 'Fraction(3, 0)' is invalid output.
I found this confusing until I worked out the dual meaning. I think

ZeroDevisionError: invalid Fraction(3, 0) from construction or division

might be a bit clearer.

I have not looked at decimals.

--
components: Interpreter Core
messages: 169410
nosy: ezio.melotti, mark.dickinson, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Add numerator to ZeroDivisionError messages
type: enhancement
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

[issue15814] memoryview: equality-hash invariant

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Am 29.08.12 20:01, schrieb Antoine Pitrou:
> >> I think the proper solution is to make memoryview objects unhashable.
> >
> > Disagreed. If memoryviews are to be bytes-like objects they should be
> > hashable (at least when readonly).
> 
> So what specific hash algorithm do you propose?

The current algorithm works well in conjunction with bytes objects.

> My claim is that any hash definition for memoryviews will have a
> *fundamental* flaw, failing to provide the basic property
> that A==B must imply hash(A)==hash(B), making it actually work
> incorrectly

Why is there such a fundamental flaw?

--

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Martin v . Löwis]

Martin v. Löwis added the comment:

Am 29.08.12 20:01, schrieb Antoine Pitrou:
>> I think the proper solution is to make memoryview objects unhashable.
>
> Disagreed. If memoryviews are to be bytes-like objects they should be
> hashable (at least when readonly).

So what specific hash algorithm do you propose?

>> Any other approach will have flaws of some kind.
>
> Not more so than equality between memoryviews.

Well, memoryviews now have a definition of equality as discussed in 
issue15573. You may disagree whether it's a useful definition, but I
don't believe it has actual flaws (in the sense that it is incorrect
or inconsistent).

My claim is that any hash definition for memoryviews will have a
*fundamental* flaw, failing to provide the basic property
that A==B must imply hash(A)==hash(B), making it actually work
incorrectly (when used for its primary application, namely keys
in dictionaries).

--

___
Python tracker 

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

[issue15800] Closing of sys.std* files in gzip test.

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I can not imagine how it can be tested. Correction does not affect the current 
behavior.

--

___
Python tracker 

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

[issue13769] json.dump(ensure_ascii=False) return str instead of unicode

[Petri Lehtinen]

Petri Lehtinen added the comment:

Attached an updated patch, which is more explicit on what ensure_ascii actually 
does.

--
Added file: http://bugs.python.org/file27049/issue13769_v2.patch

___
Python tracker 

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

[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed

[Gregory P. Smith]

Gregory P. Smith added the comment:

Here's my initial fix.

If fcntl(errpipe_write, F_DUPFD, 3) is widely available this could be shrunk a 
bit to avoid the for loop potentially calling dup a few times and tracking the 
wasted fds to close later.

Otherwise if it isn't I'd rather not bother with F_DUPFD as this code takes the 
optimal path when F_DUPFD_CLOEXEC is supported (true on all modern linux 
systems) and should cause no harm beyond a couple extra dup and close syscalls 
otherwise.

Note: Linux pipe2() support appears in kernels a few revisions after 
F_DUPFD_CLOEXEC support so the good behavior when pipe2 exists will be kept in 
this situation as that also means F_DUPFD_CLOEXEC support should exist.  The 
code will work regardless of that (incase someone has a frankenkernel, or other 
OSes choose to implement one but not the other).

--
Added file: http://bugs.python.org/file27048/issue15798-fix-gps01.diff

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Antoine Pitrou]

Antoine Pitrou added the comment:

> I think the proper solution is to make memoryview objects unhashable.

Disagreed. If memoryviews are to be bytes-like objects they should be
hashable (at least when readonly).

> Any other approach will have flaws of some kind.

Not more so than equality between memoryviews.

--

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Martin v . Löwis]

Martin v. Löwis added the comment:

I think the proper solution is to make memoryview objects unhashable. Any other 
approach will have flaws of some kind.

--

___
Python tracker 

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

[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed

[Gregory P. Smith]

Gregory P. Smith added the comment:

F_DUPFD_CLOEXEC appears exclusive to modern Linux kernels.  Any idea how wide 
spread support for plain F_DUPFD is?  If that is "everywhere" the code I've 
just whipped up could lose a lot of loops...

--

___
Python tracker 

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

[issue15573] Support unknown formats in memoryview comparisons

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
resolution:  -> fixed

___
Python tracker 

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

[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed

[Aleksey Filippov]

Aleksey Filippov added the comment:

It may be implemented simplier.
fcntl(fd, F_DUPFD_CLOEXEC, min_fd_number) will allocate new fd at least 
min_fd_number. So, it is not necessary to do a lot of dup() calls.

--

___
Python tracker 

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

[issue15805] Add stdout redirection tool to contextlib

[Brett Cannon]

Brett Cannon added the comment:

So Alex's point is valid: the examples in the unittest.mock.patch docs shows 
how to do this 
(http://docs.python.org/dev/py3k/library/unittest.mock.html#patch). So this 
could be simplified to:

def redirect_stdout(replacement=None):
  return unittest.mock.patch('sys.stdout', replacement if replacement is not 
None else io.StringIO())

Now that being said, this is extremely common, so Nick's point of just going 
ahead and providing the helper makes sense. But I wouldn't put it in contextlib 
but instead in unittest.mock since it is mocking out sys.stdout.

--
nosy: +brett.cannon

___
Python tracker 

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

[issue15573] Support unknown formats in memoryview comparisons

[Stefan Krah]

Stefan Krah added the comment:

I agree that this isn't a blocker due to the limited use of
memoryview hashing. Tracking this in #15814.

--
status: open -> closed

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Stefan Krah]

New submission from Stefan Krah:

The new PEP-3118 equality definition from #15573 that is based
on element-wise comparisons breaks the equality-hash invariant:

>>> from _testbuffer import ndarray
>>> x = ndarray([1,2,3], shape=[3], format='f')
>>> y = ndarray([1,2,3], shape=[3], format='B')
>>> a = memoryview(x)
>>> b = memoryview(y)
>>> a == b
True
>>> hash(a) == hash(b)
False
>>>

--
assignee: skrah
messages: 169398
nosy: Arfrever, christian.heimes, georg.brandl, haypo, loewis, mark.dickinson, 
meador.inge, ncoghlan, pitrou, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: memoryview: equality-hash invariant
type: behavior
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

[issue11776] Constructor signatures missing in types module documentation

[Mike Hoy]

Mike Hoy added the comment:

This should be all the requested changes. I've gone over the table entries (at 
least the first one, CodeType, with bitdancer on IRC). I've removed the 
descriptive language from below the table and added it to the table. Leaving 
the text below the table to deal with args and some descriptive text that was 
just too large to really fit into the right column of the table.

One question though, do you want:
BuiltinFunctionType
BuiltinMethodType
FrameType
GeneratorType
GetSetDescriptorType
MemberDescriptorType
TracebackType 

To be in the table as well. I'm a bit confused on this part. Just let me know.

--
Added file: 
http://bugs.python.org/file27047/complete-patch-with-table-issue-11776.diff

___
Python tracker 

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

[issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string

[David Buxton]

David Buxton added the comment:

Only a problem because I am using unicode_literals and it didn't occur to me to 
use `str('utf-8')` to get a native string on both 2+3. Much the best solution, 
thank you.

But that is still a little smelly - I think what I want ideally is for 
ElementTree to accept str or unicode on 2.7. Either way I appreciate this is 
very low priority and indeed debatable as to whether it is "wrong".

--

___
Python tracker 

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

[issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

Why is it a problem? Encoding must be a text string:
  encoding='utf-8'
works with both Python 2 and 3.

Or if you used "from __future__ import unicode_literals",
str('utf-8')
works as well.

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue15573] Support unknown formats in memoryview comparisons

[Martin v . Löwis]

Martin v. Löwis added the comment:

1. I STRONGLY request to take hashing out of this issue. The only further 
action that this issue can have is complete reversal of the patch, starting 
over. Now that the issue has been resolved, a NEW issue arises, namely that 
hashing is inconsistent with equality. Please re-read the original issue: the 
objective of supporting unknown formats in memoryview comparisons is achieved. 
Remember that by reopening the issue, you are blocking the release (since it's 
still a release blocker).

2. Any significant change to the 3.3.0 code base should, IMO, require an 
additional release candidate (since the release candidate really ought to be 
what is going to be released, hence the name, so NO changes between candidate 
and release). Do you really want to delay the release of Python 3.3 until 
October because of hashing of memoryview objects (which, AFAICT, only affects 
bytes objects in the standard library)?

3. I don't think memoryview objects should be hashable at all. No matter what 
definition of hashing you chose, you likely won't manage to get it consistent 
with ==. Since a memoryview compares equal with its underlying object, it 
should also hash equal.

4. (unrelated to hashing, related to the original issue) I think it will be 
possible to create non-transitive equalities, where 
A==memoryview(A)==memoryview(B)==B, yet not (A==B)

5. I'm not sure whether the hash of a memoryview will surely be constant (as it 
should): isn't it possible to create a read-only buffer for a mutable memory 
block (not PyObject), so that any hashing considering the contents will result 
in changing hashes? Or, since the hash is cached, couldn't that cause the hash 
to deviate from ==?

--

___
Python tracker 

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

[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed

[Gregory P. Smith]

Gregory P. Smith added the comment:

Yes, something along the lines of that patch is what I was thinking.  BTW, this 
is only necessary for the errpipe_write fd.  errpipe_read is for the parent 
process.

I'm going to do it within _create_pipe so that the optimal 
_posixsubprocess.cloexec_pipe pipe2() based implementation can be used when 
possible rather than needing to call _set_cloexec() on the dup'ed fd.

There are some recent Linux specific possibilities such as fcntl with F_DUPFD, 
or better F_DUPFD_CLOEXEC, that would make this a single call. Using that may 
be overkill for this situation but it looks easy enough while I'm in there.

--

___
Python tracker 

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

[issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string

[Eli Bendersky]

Eli Bendersky added the comment:

Thanks for the patch, David.

Alas, due to personal reasons I will not be able to work on core Python in the 
next 2-3 months. I may throw in a review here and there, but that's not a 
promise ;-)

--

___
Python tracker 

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

[issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string

[David Buxton]

David Buxton added the comment:

A patch against the current default branch to add tests for the xml_declaration 
keyword argument. This passes when applied to the 2.7 branch too.

This does NOT test whether one can use both bytes/unicode for the encoding 
argument. It just uses the native string type for each interpreter. I don't 
know whether you would actually consider that part of things worth testing yet.

--
keywords: +patch
Added file: http://bugs.python.org/file27046/xml_declaration_test.patch

___
Python tracker 

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

[issue15813] Python function decorator scope losing variable

[R. David Murray]

R. David Murray added the comment:

When you assign a value to param1 it becomes a local variable, thus the error.  
You should ask for help on your scoping questions from the python-tutor list or 
the general python-list.

--
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
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

[issue15813] Python function decorator scope losing variable

[V.E.O]

New submission from V.E.O:

I just learned python @ decorator, it's cool, but soon I found my modified code 
coming out weird problems.

def with_wrapper(param1):
def dummy_wrapper(fn):
print param1
param1 = 'new'
fn(param1)
return dummy_wrapper

def dummy():
@with_wrapper('param1')
def implementation(param2):
print param2

dummy()



I debug it, it throws out exception at print param1

UnboundLocalError: local variable 'param1' referenced before assignment

If I remove param1 = 'new' this line, without any modify operation(link to new 
object) on variables from outer scope, this routine might working.

Is it meaning I only have made one copy of outer scope variables, then make 
modification?
The policy of variable scope towards decorator is different?

--
components: Interpreter Core
messages: 169389
nosy: V.E.O
priority: normal
severity: normal
status: open
title: Python function decorator scope losing variable
type: compile error
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

[issue15591] when building the extensions, stdout is lost when stdout is redirected

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue15573] Support unknown formats in memoryview comparisons

[Stefan Krah]

Stefan Krah added the comment:

I'm trying to think of an optimization for the native types. It should 
be possible to cast any native type element to unsigned char and use the
truncated value for the bytes hash.

Well, for double probably it's required to go from double -> int64_t ->
unsigned char, otherwise the first cast is technically undefined for 
negative values, though it works with gcc.


For non-native types and compound types, Nick's suggestion of
hashing the shape and a couple of values seems to be the best
solution.


Should we do anything about this before 3.3.0?

--

___
Python tracker 

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

[issue9860] Building python outside of source directory fails

[Trent Nelson]

Changes by Trent Nelson :


--
nosy: +trent

___
Python tracker 

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

[issue15812] inspect.getframeinfo() cannot show first line

[Richard Oudkerk]

New submission from Richard Oudkerk:

When inspect.getframeinfo() tries to collect lines of context it never shows 
the first line (unless context is as big as the number of lines in the file).

The relevant code is

start = lineno - 1 - context//2
try:
lines, lnum = findsource(frame)
except IOError:
lines = index = None
else:
--> start = max(start, 1)
start = max(0, min(start, len(lines) - context))
lines = lines[start:start+context]
index = lineno - 1 - start

I think that

start = max(start, 1)

should be replaced by

start = max(start, 0)

For some reason getframeinfo() (and the functions which use it) don't seem to 
be tested by the testsuite...

--
messages: 169387
nosy: sbt
priority: normal
severity: normal
status: open
title: inspect.getframeinfo() cannot show first line

___
Python tracker 

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

[issue15803] Incorrect docstring on ConfigParser.items()

[Nathan Trapuzzano]

Nathan Trapuzzano added the comment:

Looks like the file has about an equal number of single- and double-spaces 
after periods.

--

___
Python tracker 

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

[issue15809] IDLE console uses incorrect encoding.

[Martin v . Löwis]

Martin v. Löwis added the comment:

The problem is that IDLE passes an UTF-8 encoded source string to compile, and 
compile, in the absence of a source encoding, uses the PEP 263 default source 
encoding, i.e. Latin-1.

As the consequence, the variable s has the value

u'\\xd0\\xa0\\xd1\\x83\\xd1\\x81\\xd1\\x81\\xd0\\xba\\xd0\\xb8\\xd0\\xb9 
\\xd1\\x82\\xd0\\xb5\\xd0\\xba\\xd1\\x81\\xd1\\x82'

IDLE's "Default Source Encoding" is irrelevant - it only applies to editor 
windows.

One solution for that is the attached patch. However, this patch isn't right, 
since it will cause all source to be interpreted as UTF-8. This would be wrong 
when the sys.stdin.encoding is not UTF-8, and byte string objects are created 
in interactive mode.

Interactive mode manages to get it right by looking up sys.stdin.encoding 
during compilation, but it does so only when in interactive mode (i.e. when 
tok->prompt != NULL.

I don't see any way to fix this problem in Python 2. It is fixed in Python 3, 
basically by always assuming that the source encoding is UTF-8, by making all 
string objects Unicode objects, and disallowing non-ASCII characters in bytes 
literals

--
keywords: +patch
nosy: +loewis
Added file: http://bugs.python.org/file27045/compile_unicode.diff

___
Python tracker 

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

[issue15803] Incorrect docstring on ConfigParser.items()

[Chris Jerdonek]

Chris Jerdonek added the comment:

> If the double space is used elsewhere in the same document,

You can see one above the change in the patch file.

--

___
Python tracker 

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

[issue15803] Incorrect docstring on ConfigParser.items()

[Ezio Melotti]

Ezio Melotti added the comment:

While I like to have two spaces after the period, this convenction is not 
enforced, and it usually depends on the style used in the file.
If the double space is used elsewhere in the same document, then it should be 
preserved, otherwise using a single space is OK too.

--
nosy: +ezio.melotti

___
Python tracker 

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

[issue15810] assertSequenceEqual should be fired when comparing sequence subclasses

[Ezio Melotti]

Ezio Melotti added the comment:

The assertSequenceEqual docs[0] say:
"""
This method is not called directly by assertEqual(), but it’s used to implement 
assertListEqual() and assertTupleEqual().
"""

The asserEqual docs[1] say:
"""
In addition, if first and second are the exact same type and one of list, 
tuple, dict, set, frozenset or str or any type that a subclass registers with 
addTypeEqualityFunc() the type-specific equality function will be called in 
order to generate a more useful default error message (see also the list of 
type-specific methods).
"""

assertEqual[2] calls _getAssertEqualityFunc[3] that checks if type(first) is 
type(second), so in your case no specific assert function is called, and since 
you are not comparing objects of the same type, you are not able to use 
addTypeEqualityFunc() either.

I think in this case using assertSequenceEqual() directly is ok.

[0]: 
http://docs.python.org/py3k/library/unittest.html#unittest.TestCase.assertSequenceEqual
[1]: 
http://docs.python.org/py3k/library/unittest.html#unittest.TestCase.assertEqual
[2]: http://hg.python.org/cpython/file/124fb2b39ed9/Lib/unittest/case.py#l637
[3]: http://hg.python.org/cpython/file/124fb2b39ed9/Lib/unittest/case.py#l604

--
nosy: +ezio.melotti

___
Python tracker 

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

[issue15803] Incorrect docstring on ConfigParser.items()

[Chris Jerdonek]

Chris Jerdonek added the comment:

This is a nit, but there should be two spaces after the period:

+each option in the section. Otherwise, return a list of tuples with

--
nosy: +cjerdonek

___
Python tracker 

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

[issue15803] Incorrect docstring on ConfigParser.items()

[R. David Murray]

Changes by R. David Murray :


--
stage:  -> patch review
type: enhancement -> behavior

___
Python tracker 

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

[issue15803] Incorrect docstring on ConfigParser.items()

[R. David Murray]

Changes by R. David Murray :


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue15810] assertSequenceEqual should be fired when comparing sequence subclasses

[R. David Murray]

R. David Murray added the comment:

That sounds like a bug.

--
title: assertSequenceEqual should be fired when comparing sequences -> 
assertSequenceEqual should be fired when comparing sequence subclasses

___
Python tracker 

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

[issue15810] assertSequenceEqual should be fired when comparing sequences

[Florent Xicluna]

Florent Xicluna added the comment:

you're probably right.
I will continue to use assertSequenceEqual for my use cases.
Actually, what confused me is that these assertions are True:


class T(tuple): pass
class L(list): pass

assertEqual(T('ab'), tuple('ab'))
assertEqual(L('ab'), list('ab'))

And when these tests fail, the output is not pretty formatted.

--

___
Python tracker 

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

[issue15710] logging module crashes in Python 2.7.3 for handler.setLevel(long)

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8ba6d8fc9740 by Vinay Sajip in branch '2.7':
Closes #15710: accept long in _checkLevel.
http://hg.python.org/cpython/rev/8ba6d8fc9740

--
nosy: +python-dev
resolution: invalid -> 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

[issue15807] Bogus versionchanged note in logging.handlers.MemoryHandler doc

[Roundup Robot]

Roundup Robot added the comment:

New changeset 48f54b6bf0ef by Vinay Sajip in branch '2.7':
Closes #15807: Removed incorrect directive from help.
http://hg.python.org/cpython/rev/48f54b6bf0ef

--
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> 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

[issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string

[Florent Xicluna]

Changes by Florent Xicluna :


--
components: +Library (Lib)
nosy: +eli.bendersky, flox

___
Python tracker 

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

[issue15765] test_getcwd_long_pathnames (in test_posix) kills NetBSD

[Roundup Robot]

Roundup Robot added the comment:

New changeset bfa5d0ddfbeb by Trent Nelson in branch '2.7':
Issue #15765: Fix quirky NetBSD getcwd() behaviour.
http://hg.python.org/cpython/rev/bfa5d0ddfbeb

--
nosy: +python-dev

___
Python tracker 

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

[issue9185] os.getcwd causes infinite loop on solaris

[Roundup Robot]

Roundup Robot added the comment:

New changeset bfa5d0ddfbeb by Trent Nelson in branch '2.7':
Issue #15765: Fix quirky NetBSD getcwd() behaviour.
http://hg.python.org/cpython/rev/bfa5d0ddfbeb

--
nosy: +python-dev

___
Python tracker 

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

[issue15810] assertSequenceEqual should be fired when comparing sequences

[R. David Murray]

R. David Murray added the comment:

I think it works as it should (you shouldn't be asserting that a sequence and a 
tuple are equal, after all).  Once you fix your test, you'll get the pretty 
print if there are still differences.

--
nosy: +michael.foord, r.david.murray

___
Python tracker 

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

[issue15811] ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string

[David Buxton]

New submission from David Buxton:

The problem is an inconsistency between the ElementTree.write() method on 
Python 2 and 3 when xml_declaration is True. For Python 2.7 the encoding 
argument MUST NOT be a unicode string. For Python 3.2 the encoding argument 
MUST be a unicode string.

On Python 2.7.3 (ElementTree 1.3.0) you can only use byte strings as the 
encoding argument when including the xml declaration. If you use a unicode 
object you get TypeError thrown:


>>> from xml.etree import ElementTree as ET
>>> from io import BytesIO
>>> 
>>> tree = ET.ElementTree(ET.Element(u'example'))
>>> tree.write(BytesIO(), xml_declaration=True, encoding='utf-8')
>>> tree.write(BytesIO(), xml_declaration=True, encoding=u'utf-8')
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
 line 813, in write
write("\n" % encoding)
TypeError: 'unicode' does not have the buffer interface


So the encoding argument must be a byte string.

However on Python 3.2.3 (ElementTree 1.3.0) the same argument must be a unicode 
string. If you pass a byte string in it raises TypeError.

This only happens when you pass in an encoding and xml_declaration=True. This 
is a (small) problem when writing Py 2/3 compatible code since the version of 
ElementTree is supposed to be the same.

--
components: XML
messages: 169373
nosy: David.Buxton
priority: normal
severity: normal
status: open
title: ElementTree.write() raises TypeError when xml_declaration = True and 
encoding is a unicode string
type: 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

[issue15810] assertSequenceEqual should be fired when comparing sequences

[Florent Xicluna]

New submission from Florent Xicluna:

When writing unittest, I noticed that I need to uses assertSequenceEqual 
explicitly when comparing sequences of different kinds.

If I only use the plain assertEqual, it does not generate pretty diffs.

On second thought, I think it could be fixed in unittest to use 
assertSequenceEqual when isinstance(arg, (tuple, list)) or isinstance(arg, 
collections.Sequence) is True.

--
components: Library (Lib), Tests
messages: 169372
nosy: flox
priority: normal
severity: normal
status: open
title: assertSequenceEqual should be fired when comparing sequences
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

___
Python tracker 

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

[issue15809] IDLE console uses incorrect encoding.

[alex hartwig]

alex hartwig added the comment:

Text is correct. See attachment.

--

___
Python tracker 

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

[issue15809] IDLE console uses incorrect encoding.

[Andrew Svetlov]

Changes by Andrew Svetlov :


--
title: Строки из IDLE поступают в неверной кодировке. -> IDLE console uses 
incorrect encoding.

___
Python tracker 

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

[issue15809] Строки из IDLE поступают в неверной кодировке.

[Ezio Melotti]

Ezio Melotti added the comment:

Looks like your IDLE is set to use latin-1, but s.encode('latin1') should have 
failed with an UnicodeEncodeError.  Are you sure you copied the snippet 
correctly?
The default source encoding refers to the .py files you open with IDLE, and 
doesn't affect the encoding used by IDLE itself while printing.

(Please use English to report issues.)

--
nosy: +ezio.melotti

___
Python tracker 

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

[issue15809] Строки из IDLE поступают в неверной кодировке.

[alex hartwig]

New submission from alex hartwig:

Это из IDLE:
Python 2.7.2+ (default, Oct  4 2011, 20:03:08) 
[GCC 4.6.1] on linux2
Type "copyright", "credits" or "license()" for more information.
>>> import sys
>>> import locale
>>> sys.getdefaultencoding()
'ascii'
>>> locale.getpreferredencoding()
'UTF-8'
>>> s = u'Русский текст'
>>> print s.encode('utf_8')
Русский текст
>>> print s.encode('latin1')
Русский текст

Это из консоли:
>>> import sys
>>> import locale
>>> sys.getdefaultencoding()
'ascii'
>>> locale.getpreferredencoding()
'UTF-8'
>>> s = u'Русский текст'
>>> print s.encode('utf_8')
Русский текст

--
components: IDLE
files: Снимок-2012-08-21 10:37:23.png
messages: 169369
nosy: alex.hartwig, asvetlov
priority: normal
severity: normal
status: open
title: Строки из IDLE поступают в неверной кодировке.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file27044/Снимок-2012-08-21 10:37:23.png

___
Python tracker 

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

[issue15513] Correct __sizeof__ support for pickle

[Aaron Iles]

Changes by Aaron Iles :


--
nosy: +aliles

___
Python tracker 

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

[issue15695] Correct __sizeof__ support for StgDict

[Aaron Iles]

Changes by Aaron Iles :


--
nosy: +aliles

___
Python tracker 

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

[issue15696] Correct __sizeof__ support for mmap

[Aaron Iles]

Changes by Aaron Iles :


--
nosy: +aliles

___
Python tracker 

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

[issue15436] __sizeof__ is not documented

[Aaron Iles]

Changes by Aaron Iles :


--
nosy: +aliles

___
Python tracker 

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

[issue15490] Correct __sizeof__ support for StringIO

[Aaron Iles]

Changes by Aaron Iles :


--
nosy: +aliles

___
Python tracker 

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

[issue15510] textwrap.wrap('') returns empty list

[Chris Jerdonek]

Chris Jerdonek added the comment:

Attaching an updated patch that improves the organization of the new test cases 
(test ordering, test names, and test comments, etc).

--
Added file: http://bugs.python.org/file27043/issue-15510-4.patch

___
Python tracker 

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

[issue13266] Add inspect.unwrap(f) to easily unravel "__wrapped__" chains

[Aaron Iles]

Changes by Aaron Iles :


--
nosy: +aliles

___
Python tracker 

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

[issue15806] Add context manager for the "try: ... except: pass" pattern

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

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

[issue15475] Correct __sizeof__ support for itertools

[Aaron Iles]

Changes by Aaron Iles :


--
nosy: +aliles

___
Python tracker 

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

[issue15800] Closing of sys.std* files in gzip test.

[Jesús Cea Avión]

Jesús Cea Avión added the comment:

Test?

--

___
Python tracker 

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

[issue15784] OSError.__str__() should distinguish between errno and winerror

[Richard Oudkerk]

Richard Oudkerk added the comment:

The changeset is 2e587b9bae35.

Georg, could you copy it to your release branch please.

--

___
Python tracker 

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

[issue15808] Possibility of setting custom key bindings for "Additional help sources" menu items

[Rostyslav Dzinko]

Changes by Rostyslav Dzinko :


--
versions:  -3rd party

___
Python tracker 

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

[issue15808] Possibility of setting custom key bindings for "Additional help sources" menu items

[Rostyslav Dzinko]

New submission from Rostyslav Dzinko:

There's a possibility to add additional help sources in IDLE via

Options -> Configure IDLE... -> General -> Additional Help Sources

Use case:

> If someone wants to download certain version of Python documentation in HTML 
> and specify local "index.html" to be opened by custom menu item which appears 
> the in Help menu.

Problem:

> It's not possible to assign custom hot-key (Options -> Configure IDLE... -> 
> Keys) for such menu items or reassign  to that new menu-item, which 
> actually makes sense when talking in context of the use case specified above.

This use case was taken from real life (stackoverflow site):

http://stackoverflow.com/questions/12174255/linking-offline-documentation-to-idle-linux

--
components: IDLE
messages: 169365
nosy: Rostyslav.Dzinko
priority: normal
severity: normal
status: open
title: Possibility of setting custom key bindings for "Additional help sources" 
menu items
type: enhancement
versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, 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

[issue15806] Add context manager for the "try: ... except: pass" pattern

[Eric V. Smith]

Eric V. Smith added the comment:

While the classmethod version has some appeal, it doesn't extend well to 
handling multiple exception types.

I'm -0 on this, in any event. I think the original code is more clear. Why 
force people to learn (or recognize) a second idiom for something so simple?

--
nosy: +eric.smith

___
Python tracker 

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

[issue15806] Add context manager for the "try: ... except: pass" pattern

[Antoine Pitrou]

Antoine Pitrou added the comment:

If this is desirable then I think it would be better as a classmethod of 
Exception:

with KeyError.trap():
do_something()

--
nosy: +pitrou

___
Python tracker 

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

[issue15802] Nonsensical test for mailbox

[Chris Jerdonek]

Chris Jerdonek added the comment:

> In other words, (int(groups[0]), int(groups[1])) >= (int(previous_groups[0]), 
> int(previous_groups[1])).

Why not use a single self.assertGreaterEqual() on the pairs (with an 
appropriate change in the message)?

It currently hand-codes the lexicographic comparison, which seems an 
unnecessary complication (and may have increased the likelihood of error).

--
nosy: +cjerdonek

___
Python tracker 

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

[issue13405] Add DTrace probes

[Robert Kern]

Changes by Robert Kern :


--
nosy:  -robert.kern

___
Python tracker 

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

[issue13405] Add DTrace probes

[Ronald Oussoren]

Ronald Oussoren added the comment:

It's rather annoying that dtrace doesn't honor the PATH variable, and when you 
run the strings command on /usr/lib/libdtrace.dylib you'll see that it 
hardcodes the use of gcc (not even cpp or clang).

I've filed radar 12196604 in Apple's tracker, although it is unlikely that this 
will help. BTW. You (Samuel) could also file a bugreport with Apple, the more 
people do this the higher the change that they will fix this.

--

___
Python tracker 

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

[issue15807] Bogus versionchanged note in logging.handlers.MemoryHandler doc

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +vinay.sajip
stage:  -> needs patch
versions:  -Python 2.6

___
Python tracker 

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

[issue15807] Bogus versionchanged note in logging.handlers.MemoryHandler doc

[Gunnlaugur Thor Briem]

New submission from Gunnlaugur Thor Briem:

In logging.handlers.MemoryHandler documentation:

“Changed in version 2.6: credentials was added.”

There's no `credentials` anywhere nearby, and at first glance I can't see 
anything new in `MemoryHandler` when this was introduced. Presumably the `.. 
versionchanged::` note just landed there by copy-paste error in 6fb033af9310.

--
assignee: docs@python
components: Documentation
messages: 169360
nosy: docs@python, gthb
priority: normal
severity: normal
status: open
title: Bogus versionchanged note in logging.handlers.MemoryHandler doc
type: enhancement
versions: Python 2.6, Python 2.7

___
Python tracker 

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

[issue15751] Support subinterpreters in the GIL state API

[Graham Dumpleton]

Graham Dumpleton added the comment:

If PyGILState_STATE is a struct, what happens if someone naively does:

PyGILState_Release(PyGILState_UNLOCKED)

I know they shouldn't, but I actually do this in mod_wsgi in one spot as it is 
otherwise a pain to carry around the state when I know for sure if was unlocked 
before the PyGILState_Ensure().

Or can PyGILState_UNLOCKED map to some a global struct instance with certain 
state in it that represents that without problem.

--

___
Python tracker 

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

[issue15806] Add context manager for the "try: ... except: pass" pattern

[Ezio Melotti]

Ezio Melotti added the comment:

> As with many context managers, a key benefit here is 
> in the priming effect for readers.

The "focus" is mostly on what it's being executed rather than what it's being 
ignored though.

"Do this operation and ignore these exceptions if they occur"
vs.
"Ignore these exceptions if they occur while doing this operation."

> I'm not worried that it makes things less explicit - it's pretty
> obvious what a context manager called "ignored" that accepts an
> arbitrary number of exceptions is going to do.

It's still understandable, but while I'm familiar with the semantics of 
try/except, I wouldn't be sure if e.g. this just ignored those specific 
exceptions or even their subclasses without checking the doc/code.

> One other thing it does is interact well with ExitStack - you can
> stick this in the stack of exit callbacks to suppress exceptions that
> you don't want to propagate.

This seems a good use case.

--

___
Python tracker 

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

[issue15806] Add context manager for the "try: ... except: pass" pattern

[Nick Coghlan]

Nick Coghlan added the comment:

(Note: I'm not yet convinced this is a good idea. I'm definitely considering 
it, though)

As with many context managers, a key benefit here is in the priming effect for 
readers. In this code:

try:
   # Whatever
except (A, B, C):
   pass

the reader doesn't know that (A, B, C) exceptions will be ignored until the 
end. The with statement form makes it clear before you start reading the code 
that certain exceptions won't propagate:

with ignored(A, B, C):
# Whatever

I'm not worried that it makes things less explicit - it's pretty obvious what a 
context manager called "ignored" that accepts an arbitrary number of exceptions 
is going to do.

One other thing it does is interact well with ExitStack - you can stick this in 
the stack of exit callbacks to suppress exceptions that you don't want to 
propagate.

--

___
Python tracker 

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

[issue13405] Add DTrace probes

[Samuel John]

Samuel John added the comment:

dtrace ignores PATH and CC and CPP. I tried that already :/

Of course I could just install the command line tools. But still it's a shame 
since all the tools are already there.

--

___
Python tracker 

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