[issue17810] Implement PEP 3154 (pickle protocol 4)

[Alexandre Vassalotti]

Changes by Alexandre Vassalotti :


--
dependencies: +Unbinding of methods

___
Python tracker 

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

[issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila

[Alexandre Vassalotti]

Alexandre Vassalotti added the comment:

I have started a new implementation of PEP 3154 since Stefan hasn't been active 
on his. Moving the discussion to Issue #17810.

--
dependencies:  -Unbinding of methods
resolution:  -> out of date
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> Implement PEP 3154 (pickle protocol 4)

___
Python tracker 

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

[issue17810] Implement PEP 3154 (pickle protocol 4)

[Alexandre Vassalotti]

New submission from Alexandre Vassalotti:

I have restarted the work on PEP 3154. Stefan Mihaila had begun an 
implementation as part of the Google Summer of Code 2012. Unfortunately, he hit 
multiple roadblocks which prevented him to finish his work by the end of the 
summer. He previously shown interest in completing his implementation. However 
he got constrained by time and never resumed his work.

So I am taking over the implementation of the PEP. I have decided to go forward 
with a brand new code, using Stefan's work only as a guide. At the moment, I 
have completed about half of the PEP---missing only support for calling __new__ 
with keyword arguments and the use of new qualified name for referring objects.

Design-wise, there is still a few things that we should discuss. For example, I 
think Stefan's idea, which is not specified in the PEP, to eliminate PUT 
opcodes is interesting. His proposal was to emit an implicit PUT opcode after 
each object pickled and make the Pickler and Unpickler classes agree on the 
scheme. A drawback of this implicit scheme is we cannot be selective about 
which object we save in the memo during unpickling. That means, for example, we 
won't be able to make pickletools.optimize work with protocol 4 to reduce the 
memory footprint of the unpickling process. This scheme also alters the meaning 
of all previously defined opcodes because of the implicit PUTs, which is sort 
of okay because we are changing protocol. Alternatively, we could use an 
explicit scheme by defining new "fat" opcodes, for the built-in types we care 
about, which includes memoization. This scheme would a bit more flexible 
however it would also be slightly more involved implementation-wise. In any 
 case, I will run benchmarks to see if either schemes are worthwhile.

--
assignee: alexandre.vassalotti
components: Library (Lib)
hgrepos: 184
messages: 187496
nosy: alexandre.vassalotti, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: Implement PEP 3154 (pickle protocol 4)
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

[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)

[koobs]

koobs added the comment:

There's some work that's been in the FreeBSD bleachers since Jul 2012 to add 
futimens() and utimensat(), with some recent activity:

RFC: futimens(2) and utimensat(2) - Jul 2012
http://lists.freebsd.org/pipermail/freebsd-arch/2012-February/012409.html 

RFC: futimens(2) and utimensat(2) - Jan 2013
http://lists.freebsd.org/pipermail/freebsd-arch/2013-January/013903.html 

I've also recently been made aware of a vfs.timestamp_precision sysctl and 
tested adjusting it from it's default of 0 -> 3, without success:

sysctl -d vfs.timestamp_precision
vfs.timestamp_precision: File timestamp precision (0: seconds, 1: sec + ns 
accurate to 1/HZ, 2: sec + ns truncated to ms, 3+: sec + ns (max. precision))

I'll do my best at this end to encourage the above implementation to be 
committed and request merges to other branches of FreeBSD (likely just 9-STABLE)

In the meantime however, what can be done in the short-term to either tweak the 
tests so they pass or account for the difference in implementations?

The current test failures on the buildbots make it difficult at best to ensure 
core developers are being notified or exposed to other regressions and issues 
that have cropped up in recent months.

--
nosy: +koobs

___
Python tracker 

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

[issue17809] FAIL: test_expanduser when $HOME ends with /

[koobs]

New submission from koobs:

test_expanduser in test.test_posixpath.PosixPathTest fails when the users $HOME 
ends with "/"

==
FAIL: test_expanduser (test.test_posixpath.PosixPathTest)
--
Traceback (most recent call last):
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd/build/Lib/test/test_posixpath.py", 
line 264, in test_expanduser
self.assertEqual(posixpath.expanduser("~"), home)
AssertionError: '/usr/home/buildbot' != '/usr/home/buildbot/'
- /usr/home/buildbot
+ /usr/home/buildbot/
?   +
--

Test failures can be seen in the following FreeBSD 9-STABLE buildbots on all 
branches except 2.7:

3.x - 
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%203.x/builds/1256/steps/test/logs/stdio
3.3 - 
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%203.3/builds/546/steps/test/logs/stdio
3.2 - 
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%203.2/builds/490/steps/test/logs/stdio

It is also reproducible outside of the buildbot environment using fresh Python 
3.3.1 sources with default build configuration (see attached expanduser.log)

Commenting out Lib/test/test_posixpath.py#l264 results in the test passing

--
components: Library (Lib), Tests
files: expanduser.log
messages: 187494
nosy: koobs
priority: normal
severity: normal
status: open
title: FAIL: test_expanduser when $HOME ends with /
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29964/expanduser.log

___
Python tracker 

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

[issue17800] Add gc.needs_finalizing() to check if an object needs finalising

[Alex Gaynor]

Changes by Alex Gaynor :


--
nosy: +alex, fijall

___
Python tracker 

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

[issue17800] Add gc.needs_finalizing() to check if an object needs finalising

[Nick Coghlan]

Nick Coghlan added the comment:

Antoine came up with a scheme (see issue 17807) that should eliminate the 
tp_del implementation from generator objects by moving the cleanup code to the 
frame deallocation.

This will restore Guido's original assumption that types implemented in C won't 
need to provide tp_del, so this proposal becomes obsolete.

--
dependencies:  -Generator memory leak
resolution:  -> out of date
superseder:  -> Generator cleanup without tp_del

___
Python tracker 

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

[issue17807] Generator cleanup without tp_del

[Nick Coghlan]

Nick Coghlan added the comment:

Just a couple of minor comments on review. Everything else I looked for 
(including the path where a generator failing to stop during frame deallocation 
leads to reporting an unraisable exception) seemed fine.

One aspect I find interesting is that we've had other patches which proposed 
reducing the level of poking around generators needed to do inside frame 
objects by moving (some of) that state to the generators. This patch goes the 
other way, by moving the related cleanup functionality into the frame objects.

I think that's actually a reasonable option - the frame is always going to be 
involved at some point in order to actually execute the cleanup code, so our 
only real chance to break the cycle is to eliminate the generator's involvement.

--

___
Python tracker 

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

[issue17717] Set up nasm from external.bat

[Zachary Ware]

Zachary Ware added the comment:

Could you elaborate on what you mean to be done? All I've ever had to do was 
run the nasm installer and add the install location to PATH.

--

___
Python tracker 

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

[issue17808] No code example for Event object in threading module

[Andriy Mysyk]

Andriy Mysyk added the comment:

Example added to threading.rst


For example, the following code demonstrates a controlled thread termination 
using an event object.  The event is used to request the termination of several 
threads.

import threading
import time

stopevent = threading.Event()

class TestThread(threading.Thread):
def run(self):
""" main control loop """
print ("Thread ", self.ident, " starts")
count = 0
while not stopevent.is_set():
count += 1
stopevent.wait(1.0)
print ("loop ", count, "in thread ", self.ident)
print ("Thread ", self.ident, " ends")

for i in range (2):
testthread = TestThread()
testthread.start()
time.sleep (3)
stopevent.set()

--

___
Python tracker 

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

[issue17808] No code example for Event object in threading module

[Andriy Mysyk]

Andriy Mysyk added the comment:

See the patch with a code example attached.

--
assignee:  -> docs@python
components: +Documentation
keywords: +patch
nosy: +docs@python
Added file: http://bugs.python.org/file29963/bug17808.patch

___
Python tracker 

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

[issue17808] No code example for Event object in threading module

[Andriy Mysyk]

Andriy Mysyk added the comment:

I will create a code example by the end of Sunday, April 21.

--

___
Python tracker 

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

[issue17808] No code example for Event object in threading module

[Andriy Mysyk]

New submission from Andriy Mysyk:

Documentation for Event objects in threading module could be more clear with a 
code example.

http://docs.python.org/3.4/library/threading.html#event-objects

--
messages: 187486
nosy: amysyk
priority: normal
severity: normal
status: open
title: No code example for Event object in threading module
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

[issue17807] Generator cleanup without tp_del

[Antoine Pitrou]

Antoine Pitrou added the comment:

Patch with added tests.

--
Added file: http://bugs.python.org/file29962/gen3.patch

___
Python tracker 

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

[issue17736] Misleading method comment in _elementtree.c : get_attrib_from_keywords

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +eli.bendersky
stage:  -> patch review
versions:  -Python 3.2, Python 3.5

___
Python tracker 

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

[issue17717] Set up nasm from external.bat

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +terry.reedy, zach.ware

___
Python tracker 

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

[issue17742] Add _PyBytesWriter API

[STINNER Victor]

STINNER Victor added the comment:

I'm not completly satisfied of bytes_writer-2.patch. Most encoders work 
directly on a pointer (char*). If I want to keep the code using pointers 
(because it is efficient), I have to resynchronize the writer and the pointer 
before and after calling writer methods.

Here is a new patch implementing a different approach, closer to the current 
code. The patch version 3 has no "pos" attribute: the "position" is now a 
pointer (str). So encoders can just use this pointer instead of their own 
pointer.

I expect that replacing "*p++ = c;" with "*writer.str++ = c;" would not add an 
important overhead, especially because writer is a local variable, and str is 
the first attribute of the structure. I hope that the machine code will be 
exactly the same.

--
Added file: http://bugs.python.org/file29961/bytes_writer-3.patch

___
Python tracker 

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

[issue3693] Obscure array.array error message

[Ezio Melotti]

Changes by Ezio Melotti :


--
stage: needs patch -> commit review
versions: +Python 3.4 -Python 3.2

___
Python tracker 

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

[issue17807] Generator cleanup without tp_del

[Antoine Pitrou]

Changes by Antoine Pitrou :


Added file: http://bugs.python.org/file29960/gen2.patch

___
Python tracker 

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

[issue17807] Generator cleanup without tp_del

[Antoine Pitrou]

Changes by Antoine Pitrou :


Removed file: http://bugs.python.org/file29959/gen2.patch

___
Python tracker 

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

[issue17468] Generator memory leak

[Antoine Pitrou]

Antoine Pitrou added the comment:

I've opened issue17807 for an alternative generator cleanup scheme which solves 
the present issue.

--

___
Python tracker 

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

[issue17807] Generator cleanup without tp_del

[Antoine Pitrou]

New submission from Antoine Pitrou:

This experimental patch proposes to defer generator cleanup to the frame 
itself. In this scheme, the generator frame's tp_clear throws the GeneratorExit 
if necessary, so as to call cleanup code. The generator doesn't have any tp_del 
anymore, as it is now impossible to resurrect a generator (the frame, though, 
can be resurrected; I have to add a test for that).

The net effect is that generators caught in a reference cycle can always be 
reclaimed, and their cleanup code is run in a valid frame.

--
components: Interpreter Core
files: gen2.patch
keywords: patch
messages: 187482
nosy: benjamin.peterson, ncoghlan, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Generator cleanup without tp_del
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29959/gen2.patch

___
Python tracker 

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

[issue17806] Add keyword args support to str/bytes.expandtabs()

[Ezio Melotti]

New submission from Ezio Melotti:

The attached patch adds keyword args support to str/bytes.expandtabs():
>>> 'a\tb'.expandtabs(tabsize=8)
'a   b'
>>> b'a\tb'.expandtabs(tabsize=8)
b'a   b'

--
assignee: ezio.melotti
components: Interpreter Core
files: expandtabs.diff
keywords: patch
messages: 187481
nosy: ezio.melotti
priority: normal
severity: normal
stage: patch review
status: open
title: Add keyword args support to str/bytes.expandtabs()
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29958/expandtabs.diff

___
Python tracker 

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

[issue17670] Improve str.expandtabs() doc

[Ned Deily]

Changes by Ned Deily :


Added file: http://bugs.python.org/file29957/issue17670_doc_rev_2.patch

___
Python tracker 

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

[issue17742] Add _PyBytesWriter API

[STINNER Victor]

STINNER Victor added the comment:

> It may eventually get one, though.

If a use case for the "read-only hack" comes, the hack can be added again 
later. It's better to start with something simple and extend it with new use 
cases.

--

___
Python tracker 

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

[issue17670] Improve str.expandtabs() doc

[Ned Deily]

Ned Deily added the comment:

Another round based on comments.  I also just noticed that the current doc 
incorrectly claims that tabs are replaced by *zero* or more spaces.


   Return a copy of the string where all tab characters are replaced by one or
   more spaces, depending on the current column and the given tab size.  Tab
   positions occur every *tabsize* characters (default is 8, giving tab
   positions at columns 0, 8, 16 and so on).  To expand the string, the current
   column is set to zero and the string is examined character by character.  If
   the character is a tab (``\t``), one or more space characters are inserted
   in the result until the current column is equal to the next tab position.
   (The tab character itself is not copied.)  If the character is a newline
   (``\n``) or return (``\r``), it is copied and the current column is reset to
   zero.  Any other character is copied unchanged and the current column is
   incremented by one regardless of how the character is represented when
   printed.

  >>> '01\t012\t0123\t01234'.expandtabs()
  '01  012 012301234'
  >>> '01\t012\t0123\t01234'.expandtabs(4)
  '01  012 012301234'

--

___
Python tracker 

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

[issue17742] Add _PyBytesWriter API

[R. David Murray]

R. David Murray added the comment:

It may eventually get one, though.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue17618] base85 encoding

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

There are some bugs in ascii85 end base85 implementations (see in Rietveld for 
details). Besides, ascii85 implementation was too slow. I've prepared a patch 
that corrects errors and speeds up encoding and decoding.

Microbenchmarks:

./python -m timeit -r 1 -n 1 -s "from base64 import a85encode as encode; data = 
open('python', 'rb').read(101)"  "encode(data)"
./python -m timeit -r 1 -n 1 -s "from base64 import b85encode as encode; data = 
open('python', 'rb').read(101)"  "encode(data)"
./python -m timeit -r 1 -n 1 -s "from base64 import a85encode as encode, 
a85decode as decode; data = encode(open('python', 'rb').read(101))"  
"decode(data)"
./python -m timeit -r 1 -n 1 -s "from base64 import b85encode as encode, 
b85decode as decode; data = encode(open('python', 'rb').read(101))"  
"decode(data)"

   Old patch  New patch
a85encode   8.4 sec1.13 sec
b85encode   1.35 sec   1.09 sec
a85decode   9.28 sec   3.29 sec
b85decode   3.17 sec   2.37 sec

--
Added file: http://bugs.python.org/file29956/issue17618-fast.diff

___
Python tracker 

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

[issue17742] Add _PyBytesWriter API

[STINNER Victor]

STINNER Victor added the comment:

> The patch contains a special case for writing only one bytes object.
> This is very unlikely case.

The patch only modify a few functions to make them use the new _PyBytesWriter 
API. Other functions can use it.

A few examples:

 - PyBytes_FromObject()
 - binascii: binascii_rledecode_hqx()
 - bz2, lzma and zlib modules
 - marshal and pickle modules
 - datetime.datetime.strftime()
 - Python/compile.c: assemble_lnotab()
 - more Unicode decoders

But I agree that the readonly "hack" can be removed from _PyBytesWriter API 
since the bytes type has no format method (no bytes%args nor 
bytes.format(args)).

--

___
Python tracker 

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

[issue17795] backwards-incompatible change in SysLogHandler with unix domain sockets

[Mike Lundy]

Mike Lundy added the comment:

On top of your patch? Yeah, I think so. (I wrote it the way I did so it could 
handle syslog configuration changes, but that's kind of an uncommon case).

Thanks!

--

___
Python tracker 

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

[issue16754] Incorrect shared library extension on linux

[kent]

Changes by kent :


--
nosy: +Thekent

___
Python tracker 

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

[issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths

[STINNER Victor]

STINNER Victor added the comment:

I guess that  test_extract_unicode_filenames_skip.patch will not fix the 
failing test. The test fails because u"\xf6.txt" cannot be encoded to 
sys.getfilesystemencoding() (which is ASCII on the FreeBSD buildbot). You 
should test u"\xf6.txt". You should move the try/except inside the function.

--

___
Python tracker 

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

[issue17762] platform.linux_distribution() should honor /etc/os-release

[Christian Heimes]

Changes by Christian Heimes :


--
nosy: +christian.heimes

___
Python tracker 

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

[issue17804] streaming struct unpacking

[Phil Connell]

Changes by Phil Connell :


--
nosy: +pconnell

___
Python tracker 

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

[issue17787] Optimize pickling function dispatch in hot loops.

[Antoine Pitrou]

Antoine Pitrou added the comment:

Thanks for the explanation. I guess I don't like the code duplication that this 
patch adds. Perhaps a macro hiding the "memo_get" code blocks? Also, adding 
your explanation as a comment would be nice too.

--

___
Python tracker 

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

[issue17804] streaming struct unpacking

[Antoine Pitrou]

Antoine Pitrou added the comment:

> - I'm no expert on the C API, but in s_iter_unpack do you not need to
> check for failure of PyType_GenericAlloc before calling
> PyObject_GetBuffer?

Yes, good catch.

> - I'm not a fan of separate iter_ functions (and there seemed to be a
> general move away from them elsewhere in Python3; obviously here we
> have to maintain backwards compat though). Perhaps a boolean keyword
> "asiter" arg to the regular unpack() instead?

We generally consider it bad API design when a parameter changes the
return *type* of the function. "iter_unpack" may not be terrific as a
name but it describes the semantics quite clearly (and it's not too
annoying to type).

--

___
Python tracker 

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

[issue17804] streaming struct unpacking

[Martin Morrison]

Martin Morrison added the comment:

On 20 Apr 2013, at 23:01, Martin Morrison  wrote:
> - I'm not a fan of separate iter_ functions (and there seemed to be a general 
> move away from them elsewhere in Python3; obviously here we have to maintain 
> backwards compat though). Perhaps a boolean keyword "asiter" arg to the 
> regular unpack() instead?

Thinking about this more, the functionality is probably too radically different 
to overload the same function, so I withdraw the suggestion.

--

___
Python tracker 

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

[issue17805] No such class: multiprocessing.pool.AsyncResult

[Ned Deily]

Changes by Ned Deily :


--
nosy: +sbt
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.5

___
Python tracker 

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

[issue17804] streaming struct unpacking

[Martin Morrison]

Martin Morrison added the comment:

I like the idea of this. Two comments:

- I'm no expert on the C API, but in s_iter_unpack do you not need to check for 
failure of PyType_GenericAlloc before calling PyObject_GetBuffer?

- I'm not a fan of separate iter_ functions (and there seemed to be a general 
move away from them elsewhere in Python3; obviously here we have to maintain 
backwards compat though). Perhaps a boolean keyword "asiter" arg to the regular 
unpack() instead?

--

___
Python tracker 

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

[issue17804] streaming struct unpacking

[Antoine Pitrou]

Antoine Pitrou added the comment:

For the record, here is the benchmark script.

--
Added file: http://bugs.python.org/file29955/bench_unpack.py

___
Python tracker 

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

[issue17804] streaming struct unpacking

[Antoine Pitrou]

Antoine Pitrou added the comment:

Well, according to a quick benchmark, iter_unpack() is 3x to 6x faster than the 
grouper() + unpack() recipe.
(it's also a bit more user-friendly)

--

___
Python tracker 

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

[issue17804] streaming struct unpacking

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Perhaps we need not iter_unpack(), but a grouper (some sort of)?

def grouper(seq, size):
for i in range(0, len(seq), size):
yield seq[i: i + size]

unpack = struct.Struct('!I').unpack
for chunk in grouper(data, 4):
word, = unpack(chunk)
...

--

___
Python tracker 

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

[issue17805] No such class: multiprocessing.pool.AsyncResult

[Takafumi Arakaki]

New submission from Takafumi Arakaki:

Document mentions AsyncResult but there is no such class.
http://docs.python.org/2/library/multiprocessing.html#multiprocessing.pool.AsyncResult

You can check it by simply running:
python -c 'from multiprocessing.pool import AsyncResult'

I think it means ApplyResult so I made a patch (attached).

Note that there managers.py also uses name 'AsyncResult':
% hg grep AsyncResult
Doc/library/multiprocessing.rst:83232:.. class:: AsyncResult
Lib/multiprocessing/managers.py:81039:'apply_async': 'AsyncResult',
Lib/multiprocessing/managers.py:81039:'map_async': 'AsyncResult',
Lib/multiprocessing/managers.py:81039:'starmap_async': 'AsyncResult',
Lib/multiprocessing/managers.py:81039:SyncManager.register('AsyncResult', 
create_method=False)

Probably renaming them would be better?

--
assignee: docs@python
components: Documentation
files: ApplyResult.patch
keywords: patch
messages: 187466
nosy: docs@python, tkf
priority: normal
severity: normal
status: open
title: No such class: multiprocessing.pool.AsyncResult
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 
3.4, Python 3.5
Added file: http://bugs.python.org/file29954/ApplyResult.patch

___
Python tracker 

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

[issue17547] "checking whether gcc supports ParseTuple __format__... " erroneously returns yes with gcc 4.8

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +benjamin.peterson, georg.brandl, larry
priority: normal -> release blocker

___
Python tracker 

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

[issue17804] streaming struct unpacking

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +isoschiz

___
Python tracker 

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

[issue17804] streaming struct unpacking

[Antoine Pitrou]

Antoine Pitrou added the comment:

Here is a patch (still lacking docs). Comments welcome.

--
keywords: +patch
Added file: http://bugs.python.org/file29953/iter_unpack.patch

___
Python tracker 

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

[issue17795] backwards-incompatible change in SysLogHandler with unix domain sockets

[Vinay Sajip]

Vinay Sajip added the comment:

Does that mean that if I just change the default back to socktype=None, that 
will be good enough?

--

___
Python tracker 

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

[issue17547] "checking whether gcc supports ParseTuple __format__... " erroneously returns yes with gcc 4.8

[Ned Deily]

Ned Deily added the comment:

Dave, any reason this shouldn't go into the imminent 2.7.5 and 3.3.2 releases?

--
nosy: +ned.deily
stage: patch review -> commit review
versions: +Python 2.7, Python 3.3, Python 3.4 -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

[issue17646] traceback.py has a lot of code duplication

[Martin Morrison]

Martin Morrison added the comment:

On 20 Apr 2013, at 18:55, Serhiy Storchaka  wrote:
> Serhiy Storchaka added the comment:
> 
> Could print_exception() in Lib/idlelib/run.py reuse new traceback functions?

Actually, cleaning up code like that in Idle and the code module and import.c 
was what I was aiming to solve when I stumbled upon the duplication in 
traceback.py - once this patch is in, I plan to raise a separate issue with my 
suggestion for that clean up.

To answer your question directly, the changes I've made here don't solve the 
problem, no. More invasive changes are required, which is why I raised this 
cleanup portion of my change separately (on the assumption this change alone 
wouldn't be controversial, but my wider change might be).

--

___
Python tracker 

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

[issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Here is a patch which skips test_extract_unicode_filenames if no Unicode 
filesystem semantics on this platform.

--
Added file: 
http://bugs.python.org/file29952/test_extract_unicode_filenames_skip.patch

___
Python tracker 

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

[issue17801] Tools/scripts/gprof2html.py: `#! /usr/bin/env python32.3`

[Ned Deily]

Ned Deily added the comment:

Thanks for the report!

--
nosy: +ned.deily
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.5

___
Python tracker 

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

[issue17801] Tools/scripts/gprof2html.py: `#! /usr/bin/env python32.3`

[Roundup Robot]

Roundup Robot added the comment:

New changeset 0c308d65d7bc by Ned Deily in branch '2.7':
Issue #17801: fix shebang line of gprof2html.py
http://hg.python.org/cpython/rev/0c308d65d7bc

New changeset 354e4d096c34 by Ned Deily in branch '3.3':
Issue #17801: fix shebang line of gprof2html.py
http://hg.python.org/cpython/rev/354e4d096c34

New changeset 47f392d6547d by Ned Deily in branch 'default':
Issue #17801: fix shebang line of gprof2html.py
http://hg.python.org/cpython/rev/47f392d6547d

--
nosy: +python-dev

___
Python tracker 

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

[issue17787] Optimize pickling function dispatch in hot loops.

[Alexandre Vassalotti]

Alexandre Vassalotti added the comment:

Are you asking why do we need to call both PyMemoTable_Get and memo_get? Or, 
why do we fetching the memo was moved to the save functions? For the former, 
there is no real reason. The extra call could be removed though profiling 
doesn't show this call as a hot spot.

If the latter, we need this because the patch allow save(), which is where the 
memo was fetched, to be skipped.

--

___
Python tracker 

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

[issue17804] streaming struct unpacking

[Antoine Pitrou]

Antoine Pitrou added the comment:

(my initial intuition here was to use memoryview.cast() but it doesn't support 
non-native formats)

--
nosy: +skrah

___
Python tracker 

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

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

[Antoine Pitrou]

Antoine Pitrou added the comment:

Ok, I hadn't noticed that pretty-printing a single string didn't add the 
parentheses as desired:

>>> pprint.pprint("abcd " * 6, width=15)
'abcd abcd '
'abcd abcd '
'abcd abcd '

On the other hand, the added parentheses aren't needed when inside a container 
(line continuations will work without them).

(and of course the same rules should apply to bytes objects :-))

--

___
Python tracker 

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

[issue17804] streaming struct unpacking

[Antoine Pitrou]

New submission from Antoine Pitrou:

For certain applications, you want to unpack repeatedly the same pattern. This 
came in issue17618 (base85 decoding), where you want to unpack a stream of 
bytes as 32-bit big-endian unsigned ints. The solution adopted in issue17618 
patch (struct.Struct("!{}I")) is clearly suboptimal.

I would suggest something like a iter_unpack() function which would repeatedly 
yield tuples until the bytes object is over.

--
components: Library (Lib)
messages: 187455
nosy: mark.dickinson, meador.inge, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: streaming struct unpacking
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

[issue17720] pickle.py's load_appends should call append() on objects other than lists

[Alexandre Vassalotti]

Changes by Alexandre Vassalotti :


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

___
Python tracker 

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

[issue17720] pickle.py's load_appends should call append() on objects other than lists

[Roundup Robot]

Roundup Robot added the comment:

New changeset 37139694aed0 by Alexandre Vassalotti in branch '3.3':
Isuse #17720: Fix APPENDS handling in the Python implementation of Unpickler
http://hg.python.org/cpython/rev/37139694aed0

--
nosy: +python-dev

___
Python tracker 

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

[issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths

[Christian Heimes]

Christian Heimes added the comment:

it seems like file() can't handle unicode file names on FreeBSD. The FS 
encoding is 'US-ASCII' on Snakebite's FreeBSD box.

> /home/cpython/users/christian.heimes/2.7/Lib/zipfile.py(1078)_extract_member()
-> with self.open(member, pwd=pwd) as source, \
(Pdb) self.open(member, pwd=pwd)

(Pdb) n
> /home/cpython/users/christian.heimes/2.7/Lib/zipfile.py(1079)_extract_member()
-> file(targetpath, "wb") as target:
(Pdb) file(targetpath, "wb")
*** UnicodeEncodeError: 'ascii' codec can't encode characters in position 
47-48: ordinal not in range(128)
(Pdb) sys.getfilesystemencoding()
'US-ASCII'

--

___
Python tracker 

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

[issue17785] Use faster URL shortener for perf.py

[Alexandre Vassalotti]

Changes by Alexandre Vassalotti :


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

___
Python tracker 

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

[issue17785] Use faster URL shortener for perf.py

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1488e1f55f61 by Alexandre Vassalotti in branch 'default':
Issue #17785: Use a faster URL shortener for perf.py
http://hg.python.org/benchmarks/rev/1488e1f55f61

--
nosy: +python-dev

___
Python tracker 

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

[issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +haypo

___
Python tracker 

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

[issue14805] Support display of both __cause__ and __context__

[Philip Jenvey]

Philip Jenvey added the comment:

and the code module (after #17442 is resolved)

--
nosy: +pjenvey

___
Python tracker 

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

[issue4934] tp_del and tp_version_tag undocumented

[Alex Leach]

Alex Leach added the comment:

I've just ran into tp_version_tag, when running the boost python testsuite and 
wondered what it was... Since upgrading to GCC 4.8, I've started to get a lot 
more warnings with Python extensions, e.g.:-

boost/python/opaque_pointer_converter.hpp:122:14: warning: missing initializer 
for member ‘_typeobject::tp_version_tag’ [-Wmissing-field-initializers]

In this instance the testsuite was made to compile with the '-Wextra' flag. The 
fix was pretty simple; add another zero to the opaque_pointer_convert struct.

I have used the following preprocessor macro to test whether or not to do this. 
Would this be a good way to test for the addition?

#if PY_VERSION_HEX >= 0x0206
  0,/* tp_version_tag */
#endif

Cheers,
Alex

--
nosy: +Alex.Leach

___
Python tracker 

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

[issue17795] backwards-incompatible change in SysLogHandler with unix domain sockets

[Mike Lundy]

Mike Lundy added the comment:

It doesn't fix it unless I change the configuration (and in some cases the 
code) for every SyslogHandler across all of our projects, plus every single 
library we use. Google around For "SysLogHandler /dev/log socktype" and then 
compare with "SysLogHandler /dev/log". You won't find many hits where people 
set socktype, because people knew that SyslogHandler just Did The Right Thing 
when presented with an AF_UNIX. That has been the behavior since the logging 
module was introduced in 2.3.

I'm just asking that you preserve the default behavior that has existed since 
python 2.3- that was the purpose of my patch. I'm not tied to how I implemented 
it (I mean, it is kind of ugly) but I believe preserving the behavior is 
important, and I also believe that it will break less code than what is 
currently there (because, after all, socktype was only introduced in 2.7, the 
SysLogHandler doesn't care if it's None, and subclasses couldn't have relied on 
it in the AF_UNIX case because the original fallback didn't update it)

--

___
Python tracker 

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

[issue9682] socket.create_connection error message for domain subpart with invalid length is very confusing

[R. David Murray]

R. David Murray added the comment:

The message in both branches of the if talk about empty labels, which is 
probably my fault since I got the sense of the if wrong in my suggestion.  One 
of them should be about the label being too long.  The one that should be the 
'empty' message also doesn't read right to my eyes.  As I said I think it 
should be something like: '"empty label in %r" % result.decode()'.

Also, in looking at the module code, there are several other places where the 
size check and simple message are used.  In all of these cases the string has 
already been confirmed to be (or converted to, in the case of the punycoding) 
ASCII.  So we can abstract this check into a function and call it from all 
those locations.

Do you want to update the patch accordingly, Mike?  It will need more tests.

--
assignee: loewis -> 
type: enhancement -> behavior
versions: +Python 3.3, Python 3.4 -Python 3.2

___
Python tracker 

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

[issue17409] resource.setrlimit doesn't respect -1

[Paul Price]

Paul Price added the comment:

Thanks!

--

___
Python tracker 

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

[issue14805] Support display of both __cause__ and __context__

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

And don't forget about print_exception() in Lib/idlelib/run.py.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue17646] traceback.py has a lot of code duplication

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Could print_exception() in Lib/idlelib/run.py reuse new traceback functions?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue16942] urllib still doesn't support persistent connections

[Senthil Kumaran]

Senthil Kumaran added the comment:

Agree with Demian Brecht. This issue is being closed in when two issues cover 
the requirements discussed here.

* issue# 16901 - For Enhancing FileCookieJar
* issue# 9740 - For supporting persistant HTTP 1.1 connections. 

(:-( on me)

--
nosy: +orsenthil
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> In http.cookiejar.FileCookieJar() the .load() and .revert() 
methods don't work

___
Python tracker 

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

[issue17409] resource.setrlimit doesn't respect -1

[R. David Murray]

R. David Murray added the comment:

There being no objection :) I've committed the patch.

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

[issue17409] resource.setrlimit doesn't respect -1

[Roundup Robot]

Roundup Robot added the comment:

New changeset 186f6bb3e46a by R David Murray in branch '3.3':
#17409: Document RLIM_INFINITY and use it to clarify the setrlimit docs.
http://hg.python.org/cpython/rev/186f6bb3e46a

New changeset 9c4db76d073e by R David Murray in branch '2.7':
#17409: Document RLIM_INFINITY and use it to clarify the setrlimit docs.
http://hg.python.org/cpython/rev/9c4db76d073e

New changeset f1d95b0ab66e by R David Murray in branch 'default':
Merge #17409: Document RLIM_INFINITY and use it to clarify the setrlimit docs.
http://hg.python.org/cpython/rev/f1d95b0ab66e

--
nosy: +python-dev

___
Python tracker 

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

[issue16694] Add pure Python operator module

[Antoine Pitrou]

Antoine Pitrou added the comment:

I've now commited the latest patch. Thank you very much, Zachary!

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

[issue16694] Add pure Python operator module

[Roundup Robot]

Roundup Robot added the comment:

New changeset 97834382c6cc by Antoine Pitrou in branch 'default':
Issue #16694: Add a pure Python implementation of the operator module.
http://hg.python.org/cpython/rev/97834382c6cc

--
nosy: +python-dev

___
Python tracker 

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

[issue17547] "checking whether gcc supports ParseTuple __format__... " erroneously returns yes with gcc 4.8

[Alex Leach]

Alex Leach added the comment:

The configure.ac patch works for me, on x86_64 Arch Linux. I just updated to 
GCC-4.8.0 and came across an overwhelming number of these warnings when 
compiling extension modules. Thanks for the simple fix David.

Tested on hg branch 2.7; the testsuite completes without error.

--
nosy: +Alex.Leach
versions:  -Python 2.6, Python 2.7, Python 3.3, Python 3.4, Python 3.5

___
Python tracker 

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

[issue17800] Add gc.needs_finalizing() to check if an object needs finalising

[Nick Coghlan]

Nick Coghlan added the comment:

Yeah, I've figured out that rather than exposing __del__ if tp_del is 
populated, or generalising the generator special case, the simplest way to make 
this info accessible is to be able to ask the *garbage collector* if it thinks 
an object needs finalising.

That actually makes this a pretty easy issue (as C issues go) - it's just a 
matter of exposing 
http://hg.python.org/cpython/file/default/Modules/gcmodule.c#l525 
(has_finalizer) as gc.needs_finalizing.

It will be easier once #17468 is done though, since that will make it clearer 
what the documentation should say.

--
dependencies: +Generator memory leak
keywords: +easy
title: Expose __del__ when tp_del is populated from C code -> Add 
gc.needs_finalizing() to check if an object needs finalising

___
Python tracker 

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

[issue17468] Generator memory leak

[Antoine Pitrou]

Antoine Pitrou added the comment:

> We *don't care* if the generator *would* have caught the thrown
> GeneratorExit, we only care about ensuring that finally blocks are
> executed (including those implied by with statements). So if there
> aren't any finally clauses or with statements in the block stack, we
> should be able to just let the generator and frame get collected (as
> Anssi suggested), without trying to allow execution to complete.

That's a good point.

I'm also contemplating that the generator close() could be done from the
*frame*'s tp_clear, which would sidestep the issue of collect order
entirely: the finally block doesn't actually need the generator to
execute, it only needs the frame and its locals.

--

___
Python tracker 

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

[issue17800] Expose __del__ when tp_del is populated from C code

[Benjamin Peterson]

Benjamin Peterson added the comment:

I don't understand why we need to invent a protocol for this. The gc module 
already has methods and members for introspecting the collection. I don't think 
the gen special casing currently needs to be generalized. (What would use it?)

--

___
Python tracker 

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

[issue17800] Expose __del__ when tp_del is populated from C code

[Nick Coghlan]

Nick Coghlan added the comment:

Calling __del__ explicitly shouldn't be any worse than doing the same thing for 
any other type implemented in Python (or, in the case of generators, calling 
close() multiple times). What I'm mostly interested in is the "can this type 
cause uncollectable cycles" introspection aspect.

However, as Antoine noted, generators are an interesting special case because 
the GC is able to *skip* finalising them in some cases, so exposing __del__ 
isn't right for them either (as that suggests they will *always* be 
uncollectable in a cycle, when that isn't the case).

So now I'm wondering if a better answer may be to generalise the current 
generator special case to a "__needsdel__" protocol: provide a __del__ method, 
but always make it possible for the GC to skip it when it wouldn't do anything 
(e.g. if you've already called close() explicitly). PyGenerator_NeedsFinalizing 
would then become the __needsdel__ impl for generators, and we could lose the 
special casing in the GC code. From Python, you could detect the three cases 
through:

__del__ only: can cause uncollectable cycles
__del__and __needsdel__: can cause uncollectable cycles, but it depends on the 
instance state
Neither: can't cause uncollectable cycles

--

___
Python tracker 

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

[issue17468] Generator memory leak

[Nick Coghlan]

Nick Coghlan added the comment:

To get back to Anssi's original suggestion... I think Anssi's proposal to allow 
finalisation to be skipped for try/except/else is legitimate. It's only finally 
clauses that we try to guarantee will execute, there's no such promise implied 
for ordinary except clauses.

We *don't care* if the generator *would* have caught the thrown GeneratorExit, 
we only care about ensuring that finally blocks are executed (including those 
implied by with statements). So if there aren't any finally clauses or with 
statements in the block stack, we should be able to just let the generator and 
frame get collected (as Anssi suggested), without trying to allow execution to 
complete.

--

___
Python tracker 

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

[issue17792] Unhelpful UnboundLocalError due to del'ing of exception target

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

Ezio, the problem with your patch is that it also gives a warning on this code, 
which is totally safe:

def good():
exc = None
try:
bar(int(sys.argv[1]))
except KeyError as e:
print('ke')
exc = e
except ValueError as e:
print('ve')
exc = e
print(exc)

--

___
Python tracker 

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

[issue968063] Add fileinput.islastline()

[Mark Lawrence]

Mark Lawrence added the comment:

The latest patch still applies cleanly, can we have it reviewed please.

--
nosy: +BreamoreBoy
versions: +Python 3.4 -Python 3.3

___
Python tracker 

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

[issue17468] Generator memory leak

[Nick Coghlan]

Nick Coghlan added the comment:

We can't make ordinary generators innately context managers, as it makes the 
error too hard to detect when you accidentally leave out @contextmanager when 
using a generator to write a custom one.

You can already use contextlib.closing to forcibly close them when appropriate, 
so providing a decorator to implicitly map __exit__ to close wouldn't really 
save much.

--

___
Python tracker 

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

[issue17800] Expose __del__ when tp_del is populated from C code

[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

[issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths

[koobs]

koobs added the comment:

heads-up: Tests are still failing on FreeBSD (gcc & clang) buildbots:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%202.7/builds/472/steps/test/logs/stdio
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%2Bclang%202.7/builds/468/steps/test/logs/stdio

--
nosy: +koobs

___
Python tracker 

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

[issue17192] libffi-3.0.13 import

[R. David Murray]

Changes by R. David Murray :


--
status: closed -> open

___
Python tracker 

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

[issue17800] Expose __del__ when tp_del is populated from C code

[Martin Morrison]

Changes by Martin Morrison :


--
nosy: +isoschiz

___
Python tracker 

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

[issue17646] traceback.py has a lot of code duplication

[Martin Morrison]

Martin Morrison added the comment:

On 20/04/2013 03:54, Benjamin Peterson wrote:
> It would be great to have a test for that. :)

I was afraid you'd say that. ;-)

I'll look at adding test cases to cover the functions not currently
covered (seems most of the print functions aren't, and all of the
'stack' functions aren't).

--

___
Python tracker 

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

[issue17800] Expose __del__ when tp_del is populated from C code

[Benjamin Peterson]

Benjamin Peterson added the comment:

What exactly would calling such a wrapper do?

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue17192] libffi-3.0.13 import

[koobs]

koobs added the comment:

These break what was addressed in #11729 for default, 3,x and 3.3.

2.7 seems to have made it through unscathed.

I'm not sure where or how the old code was introduced, but the clang fix has 
been upstreamed and is correct in the pure libffi 3.0.13 sources

Failure to build ctypes can be seen here:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%2Bclang%203.x/builds/1246/steps/test/logs/stdio
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%2Bclang%203.x/builds/1245/steps/test/logs/stdio
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%2Bclang%203.3/builds/538/steps/test/logs/stdio

--
nosy: +koobs

___
Python tracker 

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

[issue6359] pyexpat.c calls trace function incorrectly for exceptions

[Ned Batchelder]

Ned Batchelder added the comment:

Attached a patch which simply removes the code that invokes the trace function.

--
keywords: +patch
Added file: http://bugs.python.org/file29951/6539.patch

___
Python tracker 

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

[issue17468] Generator memory leak

[Benjamin Peterson]

Benjamin Peterson added the comment:

I realize, but if people were responsible and closed their generators, the 
second one would be as much of a problem.

--

___
Python tracker 

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

[issue14621] Hash function is not randomized properly

[Martin Morrison]

Changes by Martin Morrison :


--
nosy: +isoschiz, pconnell

___
Python tracker 

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

[issue17468] Generator memory leak

[Antoine Pitrou]

Antoine Pitrou added the comment:

Those are two different issues:
- not calling the finalizer in a timely manner
- never calling the finalizer and creating a memory leak through
gc.garbage

--

___
Python tracker 

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

[issue17468] Generator memory leak

[Benjamin Peterson]

Benjamin Peterson added the comment:

In a sense, doing something like "with self.lock" in a generator is already a 
leak. Even if there wasn't a cycle, collection could be arbitrarily delayed (in 
partincular on non-CPython VMs). I wonder if making generators context managers 
which call close() on exit would help.

--

___
Python tracker 

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

[issue17803] Calling Tkinter.Tk() with a baseName keyword argument throws UnboundLocalError

[R. David Murray]

R. David Murray added the comment:

Thanks for the report and patch.  It would be nice to turn that test into a 
unit test.

I've run the test on 3.4; this appears to be a 2.7 only bug.

--
nosy: +r.david.murray
stage:  -> test needed

___
Python tracker 

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

[issue17795] backwards-incompatible change in SysLogHandler with unix domain sockets

[Vinay Sajip]

Vinay Sajip added the comment:

I've attached an alternative patch. The default socktype stays as 
socket.SOCK_DGRAM, but you can specify socktype=None to get the SOCK_DGRAM 
falling back to SOCK_STREAM behaviour.

Can you confirm that this alternative approach works in your environment? (This 
patch is against the default branch.)

--

___
Python tracker 

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

[issue17795] backwards-incompatible change in SysLogHandler with unix domain sockets

[Vinay Sajip]

Changes by Vinay Sajip :


Added file: http://bugs.python.org/file29950/6e46f4e08717.diff

___
Python tracker 

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

[issue17795] backwards-incompatible change in SysLogHandler with unix domain sockets

[Vinay Sajip]

Changes by Vinay Sajip :


--
hgrepos: +183

___
Python tracker 

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

[issue17272] request.full_url: unexpected results on assignment

[R. David Murray]

R. David Murray added the comment:

Thanks for working on this, Demian.  I made some review comments, mostly style 
things about the tests.

There's one substantial comment about the change in behaivor of the full_url 
property though (before patch it does not include the fragment, after the patch 
it does).  We need to think about the implications of that change in terms of 
backward compatibility.  It makes more sense, but how likely is it to break 
working code?

--

___
Python tracker 

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