[issue12067] Doc: remove errors about mixed-type comparisons.

[Mark Dickinson]

Mark Dickinson  added the comment:

[Docs]
"If both are numbers, they are converted to a common type."

[Terry]
"In any case, I think it is only true for built-in number types,"

It's not even true for built-in number types.  When comparing an int with a 
float, it's definitely *not* the case that the int is converted to a float and 
the floats compared.  And that's for good reason:  the int -> float conversion 
is lossy for large integers, so if int <-> float comparisons just converted the 
int to a float before comparing, we'd have (for example):

>>> 10**16 == 1e16 == 10**16 + 1

leading to broken transitivity of equality, and strange dict and set behaviour.

So int <-> float comparisons do a complicated dance under the hood to compare 
the exact numerical values of the two objects and produce the correct result.

I'm not sure what the intent of the original sentence was, or how to reword it. 
 The key point is simply that it *is* possible to compare an int with a float, 
and that the result is sensible, based on numeric values.

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue12064] unexpected behavior with exception variable

[Mark Dickinson]

Changes by Mark Dickinson :


--
superseder:  -> except-as in Py3 eats variables

___
Python tracker 

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

[issue12066] Empty ('') xmlns attribute is not properly handled by xml.dom.minidom

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti

___
Python tracker 

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

[issue12046] Windows build identification incomplete

[Martin v . Löwis]

Martin v. Löwis  added the comment:

I'd rather not patch the build process manually during a release, so probably 
there just won't be a hg build identification in the Windows binaries, then.

--

___
Python tracker 

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

[issue10945] bdist_wininst depends on MBCS codec, unavailable on non-Windows

[Ralf Schlatterbeck]

Ralf Schlatterbeck  added the comment:

I've just been bitten by this when trying to do a new release of roundup, why 
not make the mbcs codec available on non-windows platforms as has been proposed 
(and rejected) in issue1251921 -- any non-technical reasons for not including 
this codec on other platforms?

--
nosy: +runtux

___
Python tracker 

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

[issue8954] wininst regression: errors when building on linux

[Ralf Schlatterbeck]

Ralf Schlatterbeck  added the comment:

2.6 already produces a .linux-i686.exe package instead of .win32.exe when 
running bdist_wininst. I've now used python2.5 for producing a binary windows 
installer for roundup.

--
nosy: +runtux
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

[issue10945] bdist_wininst depends on MBCS codec, unavailable on non-Windows

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

The mbcs codec depends on the Windows installation. On most Western Windows it 
is similar to cp1252, Japanese Windows will use cp932, and so on.
If we were to provide mbcs on non-windows platform, it should be an alias to 
ascii.

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

[Charles-François Natali]

Charles-François Natali  added the comment:

Antoine, I've got a couple questions concerning your patch:
- IIUC, the principle is to create a pipe for each worker process, so that when 
the child exits the read-end - sentinel - becomes readable (EOF) from the 
parent, so you know that a child exited. Then, before reading from the the 
result queue, you perform a select on the list of sentinels to check that all 
workers are alive. Am I correct?
If I am, then I have the following questions:
- have you done some benchmarking to measure the performance impact of calling 
select at every get (I'm not saying it will necessary be noticeable, I'm just 
curious)?
- isn't there a race if a process exits between the time select returns and the 
get?
- is there a distinction between a normal exit and an abnormal one? The reason 
I'm asking is because with multiprocessing.Pool, you can have a 
maxtasksperchild argument which will make workers exit after having processed a 
given number of tasks, so I'm wondering how that would be handled with the 
current patch (on the other side, I think you patch only applies to 
concurrent.futures, not to raw Queues, right?).

Finally, I might be missing something completely obvious, but I have the 
feeling that POSIX already provides something that could help solve this issue: 
process groups.
We could create a new process group for a process pool, and checking whether 
children are still alive would be as simple as waitpid(-group, os.WNOHANG) (I 
don't know anything about Windows, but Google returned WaitForMultipleObjects 
which seems to work on multiple processes). You'd get the exit code for free.

--
nosy: +neologix

___
Python tracker 

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

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Antoine, I've got a couple questions concerning your patch:
> - IIUC, the principle is to create a pipe for each worker process, so
> that when the child exits the read-end - sentinel - becomes readable
> (EOF) from the parent, so you know that a child exited. Then, before
> reading from the the result queue, you perform a select on the list of
> sentinels to check that all workers are alive. Am I correct?

Not exactly. The select is done on the queue's pipe and on the workers'
fds *at the same time*. Thus there's no race condition.

> - have you done some benchmarking to measure the performance impact of
> calling select at every get (I'm not saying it will necessary be
> noticeable, I'm just curious)?

No, but the implementation is not meant to be blazingly fast anyway
(after all, it has just been rewritten in Python from C).

> - is there a distinction between a normal exit and an abnormal one?

Not at that level. In concurrent.futures, a process exiting normally
first sends its pid on the result queue. The parent then dequeues the
pid and knows the process has ended cleanly.

This approach could work for multiprocessing.Pool as well. However, the
patch only caters with concurrent.futures indeed. 

> Finally, I might be missing something completely obvious, but I have
> the feeling that POSIX already provides something that could help
> solve this issue: process groups.
> We could create a new process group for a process pool, and checking
> whether children are still alive would be as simple as waitpid(-group,
> os.WNOHANG)

waitpid() doesn't allow for a timeout, and it doesn't allow to check a
pipe concurrently, does it?

--

___
Python tracker 

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

[issue6721] Locks in python standard library should be sanitized on fork

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> ...so how can we establish correct (cross library) locking order
> during prepare stage?

That sounds like a lost battle, if it requires the libraries'
cooperation. I think resetting locks is the best we can do. It might not
work ok in all cases, but if it can handle simple cases (such as I/O and
logging locks), it is already very good.

--

___
Python tracker 

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

[issue12068] test_logging failure in test_rollover

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 660a4a6dc2cd by Vinay Sajip in branch 'default':
Issue #12068: Fix appears to have worked; added more diagnostics for rare 
failures.
http://hg.python.org/cpython/rev/660a4a6dc2cd

--
nosy: +python-dev

___
Python tracker 

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

[issue6721] Locks in python standard library should be sanitized on fork

[Charles-François Natali]

Charles-François Natali  added the comment:

> Hi,
>

Hello Nir,

> Option (2) makes sense but is probably not always applicable.
> Option (1) depends on being able to acquire locks in locking order, but how
> can we determine correct locking order across libraries?
>

There are indeed a couple problems with 1:
1) actually, releasing the mutex/semaphore from the child is not
guaranteed to be safe, see this comment from glibc's malloc:
/* In NPTL, unlocking a mutex in the child process after a
   fork() is currently unsafe, whereas re-initializing it is safe and
   does not leak resources.  Therefore, a special atfork handler is
   installed for the child. */
We could just destroy/reinit them, though.

2) acquiring locks just before fork is probably one of the best way to
deadlock (acquiring a lock we already hold, or acquiring a lock needed
by another thread before it releases its own lock). Apart from adding
dealock avoidance/recovery mechanisms - which would be far from
trivial - I don't see how we could solve this, given that each library
can use its own locks, not counting the user-created ones

3) there's another special lock we must take into account, the GIL:
contrarily to a typical C program, we can't have the thread forking
blindly try to acquire all locks just before fork, because since we
hold the GIL, other threads won't be able to proceed (unless of course
they're in a section where they don't run without the GIL held).

So, we would have to:
- release the GIL
- acquire all locks in the correct order
- re-acquire the GIL
- fork
- reinit all locks after fork

I think this is going to be very complicated.

4) Python locks differ from usual mutexes/semaphores in that they can
be held for quite some time (for example while performing I/O). Thus,
acquiring all the locks could take a long time, and users might get
irritated if fork takes 2 seconds to complete.

5) Finally, there's a fundamental problem with this approach, because
Python locks can be released by a thread other than the one that owns
it.
Imagine this happens:

T1 T2
  lock.acquire()
  (do something without releasing lock)
fork()
lock.release()

This is perfectly valid with the current lock implementation (for
example, it can be used to implement a rendez-vous point so that T2
doesn't start processing before T1 forked worker processes, or
whatever).
But if T1 tries to acquire lock (held by T2) before fork, then it will
deadlock, since it will never be release by T2.

For all those reasons, I don't think that this approach is reasonable,
but I could be wrong :-)

> Initializing locks in child after fork without acquiring them before the
> fork may result in corrupted program state and so is probably not a good
> idea.

Yes, but in practise, I think that this shouldn't be too much of a
problem. Also note that you can very well have the same type of
problem with sections not protected explicitely by locks: for example,
if you have a thread working exclusively on an object (maybe part of a
threadpool), a fork can very well happen while the object is in an
inconsistent state. Acquiring locks before fork won't help that.
But I think this should eventually be addressed, maybe by specific
atfork handlers.

> On a positive note, if I understand correctly, Python signal handler
> functions are actually run in the regular interpreter loop (as pending
> calls) after the signal has been handled and so os.fork() atfork handlers
> will not be restricted to async-signal-safe operations (since a Python fork
> is never done in a signal handler).

That's correct.

In short, I think that we could first try to avoid common deadlocks by
just resetting locks in the child process. This is not panacea, but
this should solve the vast majority of deadlocks, and would open the
door to potential future refinements using atfork-like handlers.

Attached is a first draft for a such patch (with tests).
Synopsis:
- when a PyThread_type_lock is created, it's added to a linked-list,
when it's deleted, it's removed from the linked list
- PyOS_AfterFork() calls PyThread_ReinitLocks() which calls
PyThread_reinit_lock() for each lock in the linked list
- PyThread_reinit_lock() does the right thing (i.e. sem_destroy/init
for USE_SEMAPHORES and pthread_(mutex|cond)_destroy/init for emulated
semaphores).

Notes:
- since it's only applicable to POSIX (since other Unix thread
implementations will be dropped), I've only defined a
PyThread_ReinitLocks inside Python/thread_pthread.h, so it won't build
on other platforms. How should I proceed: like PyThread_ReInitTLS(),
add a stub function to all Python/thread_xxx.h, or guard the call to
PyThread_ReinitLocks() with #ifdef _POSIX_THREADS ?
- I'm not sure of how to handle sem_init/etc failures in the reinit
code: for now I just ignore this possibility, like what's done for the
import lock reset
- insertions/removals from the linked list are not protected from
con

[issue12013] file /usr/local/lib/python3.1/lib-dynload/_socket.so: symbol inet_aton: referenced symbol not found

[Éric Araujo]

Éric Araujo  added the comment:

> Is the original bug still present in your new install?
I meant your server.  I’d like to know whether this is a legit but or not.

--

___
Python tracker 

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

[issue3871] cross and native build of python for mingw32 with distutils

[Ralf Schmitt]

Changes by Ralf Schmitt :


--
nosy: +schmir

___
Python tracker 

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

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

[Charles-François Natali]

Charles-François Natali  added the comment:

> Not exactly. The select is done on the queue's pipe and on the workers'
> fds *at the same time*. Thus there's no race condition.

You're right, I missed this part, it's perfectly safe.

But I think there's a problem with the new implementation in Python.
Writes to a pipe are guaranteed to be atomic if you write less than
PIPE_BUF (4K on Linux, 512 by POSIX) at a time. Writes to a datagram
Unix domain socket are also atomic.
But Lib/multiprocessing/connection.py does:

def _send_bytes(self, buf):
# For wire compatibility with 3.2 and lower
n = len(buf)
self._send(struct.pack("=i", len(buf)))
# The condition is necessary to avoid "broken pipe" errors
# when sending a 0-length buffer if the other end closed the pipe.
if n > 0:
self._send(buf)

This is definitely not atomic. If two processes write objects of
different size at the same time, it can probably lead to trouble.
Also, Pipe(duplex=True) should probably return a SOCK_DGRAM Unix
socket for the same reason.
If I missed something here, I promise to shut up ;-)

--

___
Python tracker 

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

[issue8954] wininst regression: errors when building on linux

[Éric Araujo]

Éric Araujo  added the comment:

2.6 only gets security fixes.

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

[issue6011] python doesn't build if prefix contains non-ascii characters

[Baptiste Carvello]

Baptiste Carvello  added the comment:

Indeed, I retried with 534a9e274d88 (that was the tip of 3.2 sometime 
yesterday) and my original problem is solved. Thank you.

While I was at it, I ran "make test",  and got 3 unusual skips and 1 
failure.

The skips are test_sax, test_xml_etree and test_xml_etree_c and they are 
skipped on purpose when the example XML filename is not encodable to 
utf8. No problem here.

The failure is for test_distutils. 3 individual tests are failing: 
test_simple_built, test_debug_mode and test_record. The cause of this 
failure is that the "install" command installs a test distribution to a 
path containing sys.prefix. This is not a problem per se, but later 
test_simple_built tries to zip this distribution, and cannot construct a 
valid archive name. A similar problem happens when test_record tries to 
write the distribution's filenames to a record file (and test_debug_mode 
fails because of test_record).

Imho those failures cannot be fixed, so the only possible improvement is 
to skip those tests. The attached trivial patch does just that, but I'm 
not sure if it's worth patching distutils for that.

Cheers,
Baptiste

--
Added file: http://bugs.python.org/file21992/test_distutils_surrogateescape.diff

___
Python tracker 

___diff --git a/Lib/distutils/tests/test_bdist_dumb.py 
b/Lib/distutils/tests/test_bdist_dumb.py
--- a/Lib/distutils/tests/test_bdist_dumb.py
+++ b/Lib/distutils/tests/test_bdist_dumb.py
@@ -24,6 +24,12 @@
 except ImportError:
 ZLIB_SUPPORT = False
 
+try:
+os.path.normpath(sys.prefix).encode("utf8")
+PREFIX_NOT_UTF8 = False
+except UnicodeEncodeError:
+PREFIX_NOT_UTF8 = True
+
 
 class BuildDumbTestCase(support.TempdirManager,
 support.LoggingSilencer,
@@ -42,6 +48,7 @@
 super(BuildDumbTestCase, self).tearDown()
 
 @unittest.skipUnless(ZLIB_SUPPORT, 'Need zlib support to run')
+@unittest.skipIf(PREFIX_NOT_UTF8, 'prefix is not encodable to utf8')
 def test_simple_built(self):
 
 # let's create a simple package
diff --git a/Lib/distutils/tests/test_install.py 
b/Lib/distutils/tests/test_install.py
--- a/Lib/distutils/tests/test_install.py
+++ b/Lib/distutils/tests/test_install.py
@@ -16,6 +16,13 @@
 
 from distutils.tests import support
 
+try:
+os.path.normpath(sys.prefix).encode("utf8")
+PREFIX_NOT_UTF8 = False
+except UnicodeEncodeError:
+PREFIX_NOT_UTF8 = True
+
+
 class InstallTestCase(support.TempdirManager,
   support.EnvironGuard,
   support.LoggingSilencer,
@@ -166,6 +173,7 @@
 cmd.user = 'user'
 self.assertRaises(DistutilsOptionError, cmd.finalize_options)
 
+@unittest.skipIf(PREFIX_NOT_UTF8, 'prefix is not encodable to utf8')
 def test_record(self):
 
 install_dir = self.mkdtemp()
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> But Lib/multiprocessing/connection.py does:
> 
> def _send_bytes(self, buf):
> # For wire compatibility with 3.2 and lower
> n = len(buf)
> self._send(struct.pack("=i", len(buf)))
> # The condition is necessary to avoid "broken pipe" errors
> # when sending a 0-length buffer if the other end closed the pipe.
> if n > 0:
> self._send(buf)
> 
> This is definitely not atomic.

Indeed, it isn't, Pipe objects are not meant to be safe against multiple
access. Queue objects (in multiprocessing/queues.py) use locks so they
are safe.

--

___
Python tracker 

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

[issue11965] Simplify context manager in os.popen

[Éric Araujo]

Éric Araujo  added the comment:

After #12044, subprocess.Popen.__exit__ waits for process completion and closes 
streams.  Doesn’t that make wrap_close obsolete?

--

___
Python tracker 

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

[issue12013] file /usr/local/lib/python3.1/lib-dynload/_socket.so: symbol inet_aton: referenced symbol not found

[Alex Lai]

Alex Lai  added the comment:

No bugs.

--

___
Python tracker 

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

[issue6011] python doesn't build if prefix contains non-ascii characters

[Éric Araujo]

Changes by Éric Araujo :


--
assignee: tarek -> haypo

___
Python tracker 

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

[issue12013] file /usr/local/lib/python3.1/lib-dynload/_socket.so: symbol inet_aton: referenced symbol not found

[Éric Araujo]

Éric Araujo  added the comment:

All right.  Don’t hesitate to report any other bugs you find in the future.

--
resolution:  -> invalid
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

[issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3" but "10.5" during configure

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I'll apply the patch late tonight (I won't be home until at least 22:30 CEST)

--

___
Python tracker 

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

[issue12070] Unlimited loop in sysconfig._parse_makefile()

[STINNER Victor]

New submission from STINNER Victor :

$ ./python -c "import sysconfig; sysconfig._parse_makefile('Makefile.loop')"

It loops on the following variables:

'DESTSHARED'='$(BINLIBDEST)/lib-dynload'
'INCLDIRSTOMAKE'='$(INCLUDEDIR) $(CONFINCLUDEDIR) $(INCLUDEPY) $(CONFINCLUDEPY)'
'CONFINCLUDEPY'='$(CONFINCLUDEDIR)/python$(LDVERSION)'
'DESTLIB'='$(LIBDEST)'
'INCLUDEPY'='$(INCLUDEDIR)/python$(LDVERSION)'
'MANDIR'='${datarootdir}/man'
'DESTDIRS'='$(exec_prefix) $(LIBDIR) $(BINLIBDEST) $(DESTSHARED)'
'CONFINCLUDEDIR'='$(exec_prefix)/include'
'exec_prefix'='${prefix}'
'LIBDIR'='${exec_prefix}/lib'
'LIBDEST'='$(SCRIPTDIR)/python$(VERSION)'
'INCLUDEDIR'='${prefix}/include'
'BINDIR'='${exec_prefix}/bin'
'LIBPC'='$(LIBDIR)/pkgconfig'
'datarootdir'='${prefix}/share'
'SCRIPTDIR'='$(prefix)/lib'
'BINLIBDEST'='$(LIBDIR)/python$(VERSION)'
'LIBPL'='$(LIBDEST)/config-$(LDVERSION)'
'MACHDESTLIB'='$(BINLIBDEST)'

I had the bug while trying to debug #6011.

--
components: Library (Lib)
messages: 135909
nosy: haypo
priority: normal
severity: normal
status: open
title: Unlimited loop in sysconfig._parse_makefile()
versions: Python 3.3

___
Python tracker 

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

[issue12070] Unlimited loop in sysconfig._parse_makefile()

[STINNER Victor]

Changes by STINNER Victor :


Added file: http://bugs.python.org/file21993/Makefile.loop

___
Python tracker 

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

[issue12070] Unlimited loop in sysconfig._parse_makefile()

[STINNER Victor]

STINNER Victor  added the comment:

My OS is Debian Sid. Important note: I use LC_ALL=C and so ASCII locale 
encoding.

--

___
Python tracker 

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

[issue12071] test_concurrent_futures hangs on OpenIndiana

[STINNER Victor]

New submission from STINNER Victor :

test_concurrent_futures of Python 3.3 (rev [6d8678555c04]) hangs on 
OpenIndiana. I dumped manually the tracebacks of the parent process 
(test_concurrent_futures) and of the 3 child processes. In the parent process, 
the test hangs when exiting the context manager:

-
def test_context_manager_shutdown(self):
with futures.ProcessPoolExecutor(max_workers=5) as e:
processes = e._processes
self.assertEqual(list(e.map(abs, range(-5, 5))),
 [5, 4, 3, 2, 1, 0, 1, 2, 3, 4])
### HERE #
for p in processes:
p.join()
-

I may be related to issue #9205.

Have fun with the following tracebacks!

[123/354] test_concurrent_futures

=== Parent ===

Thread 0x04af:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x04ae:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in 
_recv
chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in 
_recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in 
_queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x04a0:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x049f:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in 
_recv
chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in 
_recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in 
_queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x049e:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x049d:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in 
_recv
chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in 
_recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in 
_queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0479:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0478:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in 
_recv
chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in 
_recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.

[issue12071] test_concurrent_futures.test_context_manager_shutdown() hangs on OpenIndiana

[STINNER Victor]

Changes by STINNER Victor :


--
title: test_concurrent_futures hangs on OpenIndiana -> 
test_concurrent_futures.test_context_manager_shutdown() hangs on OpenIndiana

___
Python tracker 

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

[issue6011] python doesn't build if prefix contains non-ascii characters

[STINNER Victor]

Changes by STINNER Victor :


--
resolution: fixed -> 
status: closed -> 

___
Python tracker 

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

[issue8604] Adding an atomic FS write API

[Charles-François Natali]

Charles-François Natali  added the comment:

Something's missing in all the implementations presented:
to make sure that the new version of the file is available afer a crash, fsync 
must be called on the containing directory after the rename.

--
nosy: +neologix

___
Python tracker 

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

[issue12013] file /usr/local/lib/python3.1/lib-dynload/_socket.so: symbol inet_aton: referenced symbol not found

[dario frascatani]

dario frascatani  added the comment:

I guys I have the same problem with solaris 10 and the pre-compiled package 
python-3.1.2 downloaded from sunfreeware.com

--
nosy: +drdevious

___
Python tracker 

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

[issue12013] file /usr/local/lib/python3.1/lib-dynload/_socket.so: symbol inet_aton: referenced symbol not found

[Éric Araujo]

Éric Araujo  added the comment:

Can you download a Python 3.1.3 from python.org (or better, clone the 3.1 
repository from hg.python.org), try to compile it and report errors?  We can’t 
do anything for files provided by sunfreeware, but we can fix platform-specific 
problems if they come from our code.

--

___
Python tracker 

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

[issue11617] Sporadic failure in test_httpservers

[STINNER Victor]

STINNER Victor  added the comment:

The issue looks to be fixed. Reopen if there are new failures.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue11873] test_regexp() of test_compileall fails occassionally

[Éric Araujo]

Éric Araujo  added the comment:

> You are right that I got the regex wrong (I'm bad at regexes), but in
> fact it is fine the way it is.  Since there's no r, the regex is
> actually "ba[^/]$", which is exactly what I meant.

I would edit the string to reflect your meaning, then, otherwise other people 
may think too that the r was forgotten.

--

___
Python tracker 

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

[issue8604] Adding an atomic FS write API

[Milko Krachounov]

Milko Krachounov  added the comment:

> Something's missing in all the implementations presented:
> to make sure that the new version of the file is available afer 
> a crash, fsync must be called on the containing directory after 
> the rename.

I upgraded my proposed approach to include dir fsync, and to do a copy when 
backing up instead of rename (is that good?)

http://bazaar.launchpad.net/~exabyte/blackherd/async-refactor/view/66/blackherd/misc.py#L498

--

___
Python tracker 

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

[issue11964] Undocumented change to indent param of json.dump in 3.2

[Éric Araujo]

Éric Araujo  added the comment:

It turns out that only one documentation block talks about the new indent 
behavior.  It was easy to add a versionchanged directive to that, but I think a 
complete patch would fix all mentions of the indent argument, after checking 
that all of encode/dump/dumps/Encoder.whatnot support the new behavior (there 
is a test for dumps only, I checked that dump works too but not the other ones).

--

___
Python tracker 

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

[issue11873] test_regexp() of test_compileall fails occassionally

[STINNER Victor]

Changes by STINNER Victor :


--
resolution: fixed -> 
status: closed -> 

___
Python tracker 

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

[issue12071] test_concurrent_futures.test_context_manager_shutdown() hangs on OpenIndiana

[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

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

[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

[issue11377] Deprecate (remove?) platform.popen()

[Éric Araujo]

Éric Araujo  added the comment:

Is it on purpose that there is a doc deprecation but no 
[Pending]DeprecationWarning?

--
nosy: +eric.araujo

___
Python tracker 

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

[issue11377] Deprecate (remove?) platform.popen()

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Éric Araujo wrote:
> 
> Éric Araujo  added the comment:
> 
> Is it on purpose that there is a doc deprecation but no 
> [Pending]DeprecationWarning?

No, I guess just an oversight.

--

___
Python tracker 

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

[issue11996] libpython.py: nicer py-bt output

[Roundup Robot]

Roundup Robot  added the comment:

New changeset b340d1577dc5 by Victor Stinner in branch '3.2':
Issue #11996: libpython (gdb), replace "py-bt" command by "py-bt-full" and add
http://hg.python.org/cpython/rev/b340d1577dc5

New changeset 804abc2c60de by Victor Stinner in branch 'default':
(Merge 3.2) Issue #11996: libpython (gdb), replace "py-bt" command by
http://hg.python.org/cpython/rev/804abc2c60de

--
nosy: +python-dev

___
Python tracker 

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

[issue11786] ConfigParser.[Raw]ConfigParser optionxform()

[Éric Araujo]

Changes by Éric Araujo :


--
status: closed -> pending
title: ConfigParser. -> ConfigParser.[Raw]ConfigParser optionxform()

___
Python tracker 

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

[issue11996] libpython.py: nicer py-bt output

[STINNER Victor]

STINNER Victor  added the comment:

Without any reaction from Dave Malcolm, I kept its name under the name 
"py-bt-full".

> I would also like a less verbose output for where, especially
> be able to hidden the value of the globals argument of
> PyEval_EvalCodeEx.

Well, I will maybe open a new issue for this one. But I consider that the work 
is done on this issue so I close it.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue12069] test_signal.test_without_siginterrupt() failure on AMD64 OpenIndiana 3.x

[STINNER Victor]

STINNER Victor  added the comment:

I'm unable to reproduce the issue using regrtest.py -F test_signal. It is maybe 
a race condition, or another test has a border effect of test_signal?

--

___
Python tracker 

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

[issue10761] tarfile.extractall fails to overwrite symlinks

[Scott Leerssen]

Scott Leerssen  added the comment:

It turns out that my fix was at least one byte short of complete.  If the 
target pathname is a broken symlink, os.path.exists() returns False, and the 
OSError is raised.  I should have used os.path.lexists().  Also, I believe the 
same problem exists for the hardlink case a few lines below.

--

___
Python tracker 

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

[issue10761] tarfile.extractall fails to overwrite symlinks

[Scott Leerssen]

Scott Leerssen  added the comment:

here is a diff of a better fix based on the previous patch:


Index: tarfile.py
===
--- tarfile.py  (revision 49758)
+++ tarfile.py  (working copy)
@@ -2239,12 +2239,14 @@
 if hasattr(os, "symlink") and hasattr(os, "link"):
 # For systems that support symbolic and hard links.
 if tarinfo.issym():
-if os.path.exists(targetpath):
+if os.path.lexists(targetpath):
 os.unlink(targetpath)
 os.symlink(tarinfo.linkname, targetpath)
 else:
 # See extract().
 if os.path.exists(tarinfo._link_target):
+if os.path.lexists(targetpath):
+os.unlink(targetpath)
 os.link(tarinfo._link_target, targetpath)
 else:
 self._extract_member(self._find_link_target(tarinfo), 
targetpath)

--

___
Python tracker 

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

[issue10761] tarfile.extractall fails to overwrite symlinks

[Scott Leerssen]

Scott Leerssen  added the comment:

tests that verify the bug/fix:


def test_extractall_broken_symlinks(self):
# Test if extractall works properly when tarfile contains symlinks
tempdir = os.path.join(TEMPDIR, "testsymlinks")
temparchive = os.path.join(TEMPDIR, "testsymlinks.tar")
os.mkdir(tempdir)
try:
source_file = os.path.join(tempdir,'source')
target_file = os.path.join(tempdir,'symlink')
with open(source_file,'w') as f:
f.write('something\n')
os.symlink(source_file, target_file)
tar = tarfile.open(temparchive,'w')
tar.add(target_file, arcname=os.path.basename(target_file))
tar.close()
# remove the real file
os.unlink(source_file)
# Let's extract it to the location which contains the symlink
tar = tarfile.open(temparchive,'r')
# this should not raise OSError: [Errno 17] File exists
try:
tar.extractall(path=tempdir)
except OSError:
self.fail("extractall failed with broken symlinked files")
finally:
tar.close()
finally:
os.unlink(temparchive)
shutil.rmtree(TEMPDIR)

def test_extractall_hardlinks(self):
# Test if extractall works properly when tarfile contains symlinks
TEMPDIR = tempfile.mkdtemp()
tempdir = os.path.join(TEMPDIR, "testsymlinks")
temparchive = os.path.join(TEMPDIR, "testsymlinks.tar")
os.mkdir(tempdir)
try:
source_file = os.path.join(tempdir,'source')
target_file = os.path.join(tempdir,'symlink')
with open(source_file,'w') as f:
f.write('something\n')
os.link(source_file, target_file)
tar = tarfile.open(temparchive,'w')
tar.add(source_file, arcname=os.path.basename(source_file))
tar.add(target_file, arcname=os.path.basename(target_file))
tar.close()
# Let's extract it to the location which contains the symlink
tar = tarfile.open(temparchive,'r')
# this should not raise OSError: [Errno 17] File exists
try:
tar.extractall(path=tempdir)
except OSError:
self.fail("extractall failed with linked files")
finally:
tar.close()
finally:
os.unlink(temparchive)
shutil.rmtree(TEMPDIR)

--

___
Python tracker 

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

[issue12024] 2.6 svn and hg branches are out of sync

[Éric Araujo]

Éric Araujo  added the comment:

I guess release for stable branches (especially venerable branches in security 
mode) should be made from Subversion.  Who know what code could break without a 
meaningful sys.subversion?

--
nosy: +eric.araujo

___
Python tracker 

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

[issue12029] ABC registration of Exceptions

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

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

[issue12043] Update shutil documentation

[Éric Araujo]

Éric Araujo  added the comment:

“it seems to”: does this come from the mailing list?

--
nosy: +eric.araujo

___
Python tracker 

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

[issue12040] Expose a Process.sentinel property (and fix polling loop in Process.join())

[Gregory P. Smith]

Gregory P. Smith  added the comment:

That looks better. :)

btw, that eintr_retry utility probably deserves to be in a more
prominent place in the stdlib but I don't have a good suggestion as to
where at the moment.  I believe similar code exists in many places in
the code base.

If it is not going to be documented as an official
multiprocessing.util function, rename it to _eintr_retry().  that way
it'll be easier to move to a new place in the library if/when we do
want to make it public.

--

___
Python tracker 

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

[issue12040] Expose a Process.sentinel property (and fix polling loop in Process.join())

[Charles-François Natali]

Charles-François Natali  added the comment:

Just a detail, but with the last version, select is retried with the full 
timeout (note that the signal you're the most likely to receive is SIGCHLD and 
since it's ignored by default it won't cause EINTR, so this shouldn't happen 
too often).
By the way, it's not the first time EINTR-issues pop up: would it be 
possible/worth it/interesting to expose this kind of wrapper somewhere (even as 
a private API), or a context manager ?

--

___
Python tracker 

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

[issue12043] Update shutil documentation

[Fred L. Drake, Jr.]

Changes by Fred L. Drake, Jr. :


--
nosy: +fdrake

___
Python tracker 

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

[issue2521] ABC caches should use weak refs

[H.]

H.  added the comment:

ImportError: No module named _weakrefset
Here are some references while i was trying to install Pinax framework.

http://paste.pound-python.org/show/6536/

And i saw that the _weakrefset.py is not included in the package. So I have 
copied from Python's source with version : 3.1.* to my d:\sosyal\ folder. and 
everything works fine.

--
nosy: +bluag

___
Python tracker 

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

[issue11948] Tutorial/Modules - small fix to better clarify the modules search path

[Éric Araujo]

Éric Araujo  added the comment:

About Terry’s suggestion to change "This allows Python programs to modify or 
replace the module search path" to "After initialization, Python programs can 
modify sys.path": IMO the old text is talking about intent (modify the module 
search path) and the replacement about implementation (modify sys.path).  I 
prefer the former; what do you think?

--

___
Python tracker 

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

[issue12071] test_concurrent_futures.test_context_manager_shutdown() hangs on OpenIndiana

[Charles-François Natali]

Charles-François Natali  added the comment:

Interesting.
There's something weird with the first child:

=== Child #1 =

Thread 0x0445:

Thread 0x0444:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
waiter.acquire()
  File "/home/haypo/cpython/Lib/threading.py", line 423 in wait
  File "/home/haypo/cpython/Lib/threading.py", line 685 in start
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 187 in 
_start_thread
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 107 in put
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 168 in 
_add_call_item_to_queue
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 206 in 
_queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

See the last thread created (0x0445)?
0x0444 bootstrapped 0x0445, and is waiting for it to signal that it's 
running.
Since there's no backtrace for this thread, it means that it's stuck inside 
t_bootstrap or really early in the call stack (or didn't start at all?).
You don't have a coredump, do you?
I guess it's not reproductible either?

--
nosy: +neologix

___
Python tracker 

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

[issue11377] Deprecate platform.popen()

[Éric Araujo]

Éric Araujo  added the comment:

haypo asked me on IRC if I’d like to make a patch for this; I will, in some 
weeks.

With respect to the recent thread about deprecations and 2.7 → 3. 
migrations, should this be a DeprecationWarning or PendingDeprecationWarning?  
Neither is displayed by default, but using PDW would put the actual removal a 
version later.  I’m not sure about the timeframe here.

--
assignee:  -> eric.araujo
resolution: fixed -> 
stage:  -> needs patch
status: closed -> open
title: Deprecate (remove?) platform.popen() -> Deprecate platform.popen()

___
Python tracker 

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

[issue2521] ABC caches should use weak refs

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

bluag: the script you run contains a list of some modules required to start 
Python
(I found a copy here: 
https://github.com/pinax/pinax/raw/master/scripts/pinax-boot.py )
This script is obviously out of date wrt the new version of Python. Please 
report this to the pinax project!

--

___
Python tracker 

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

[issue10761] tarfile.extractall fails to overwrite symlinks

[Scott Leerssen]

Scott Leerssen  added the comment:

oops... I left some of my local edits in those tests.  be sure to fix the 
TEMPDIR use if you add these into the tarfile tests.

--

___
Python tracker 

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

[issue11948] Tutorial/Modules - small fix to better clarify the modules search path

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I disagree (else I would not have suggested change ;-). First, I dislike 'This 
allows' on stylistic grounds, when there is a better alternative. It is rather 
wishy-washy: 'this allows' -- so what? As for the rest -- why not be specific? 
The whole paragraph is about sys.path, so it is not an hidden detail.

--

___
Python tracker 

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

[issue12072] Missing parenthesis in c-api/buffer PyBuffer_FillContiguousStrides

[Sandro Tosi]

New submission from Sandro Tosi :

Following up with http://mail.python.org/pipermail/docs/2011-April/004159.html 
here's a tiny patch to add a missing parenthesis.

--
assignee: docs@python
components: Documentation
files: capi_buffer_PyBuffer_FillContiguousStrides-py27.patch
keywords: patch
messages: 135938
nosy: docs@python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Missing parenthesis in c-api/buffer PyBuffer_FillContiguousStrides
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: 
http://bugs.python.org/file21994/capi_buffer_PyBuffer_FillContiguousStrides-py27.patch

___
Python tracker 

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

[issue12043] Update shutil documentation

[Sandro Tosi]

Sandro Tosi  added the comment:

nope, from a quick glance at the docstrings text and what's on the ReST 
documentation - was I a bit too catastrophic? :)

--

___
Python tracker 

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

[issue11948] Tutorial/Modules - small fix to better clarify the modules search path

[Éric Araujo]

Éric Araujo  added the comment:

> First, I dislike 'This allows' on stylistic grounds
Fully agreed, sir!

> The whole paragraph is about sys.path, so it is not an hidden detail.
It may be that I miss context; I don’t actually know whether the paragraph is 
only about sys.path or about module search in general.  Apologies if my 
comments are only noise.  This is my last proposal:

“After initialization, Python programs can modify sys.path to modify or replace 
the module search path (except for built-in modules)”

If it’s redundant, then +1 to your earlier suggestion.

--

___
Python tracker 

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

[issue12043] Update shutil documentation

[Éric Araujo]

Éric Araujo  added the comment:

No, it’s just the wording that made me think you were referring to other 
reports or to posts.

--

___
Python tracker 

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

[issue11948] Tutorial/Modules - small fix to better clarify the modules search path

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Sandro, thank you for sticking with this. Seemingly simples issues sometimes 
'explode' a bit. Having reviewed the patch, I think the it is ready to be 
committed.

Éric: if you were to commit this and, in the process, wanted to change sys.path 
back to 'this module search path' ('this' instead of 'the' to refer back to the 
definition of sys.path just given), I would not object.

--

___
Python tracker 

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

[issue11948] Tutorial/Modules - small fix to better clarify the modules search path

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
stage: patch review -> commit review

___
Python tracker 

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

[issue11377] Deprecate platform.popen()

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Éric Araujo wrote:
> 
> Éric Araujo  added the comment:
> 
> haypo asked me on IRC if I’d like to make a patch for this; I will, in some 
> weeks.
> 
> With respect to the recent thread about deprecations and 2.7 → 3. 
> migrations, should this be a DeprecationWarning or PendingDeprecationWarning? 
>  Neither is displayed by default, but using PDW would put the actual removal 
> a version later.  I’m not sure about the timeframe here.

Please follow the PEP 387 guidelines. We are starting the deprecation
process with 3.3. I don't think we need a PendingDeprecationWarning
in 3.3, but we might want to add one to 2.7.

--

___
Python tracker 

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

[issue12068] test_logging failure in test_rollover

[Vinay Sajip]

Changes by Vinay Sajip :


--
resolution:  -> duplicate
status: open -> closed

___
Python tracker 

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

[issue12068] test_logging failure in test_rollover

[Vinay Sajip]

Changes by Vinay Sajip :


--
resolution: duplicate -> fixed

___
Python tracker 

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

[issue12042] What's New multiprocessing example error

[Jordan Stadler]

Jordan Stadler  added the comment:

I'll prepare the patch if davipo doesn't want to. I'm trying to become more 
comfortable with the patching process and this seems simple enough for me to 
handle.

--
nosy: +jstadler

___
Python tracker 

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

[issue12070] Unlimited loop in sysconfig._parse_makefile()

[STINNER Victor]

STINNER Victor  added the comment:

Oh, the problem is that the prefix variable value is seen as "bogus" 
($/home/haypo/...: $ is a typo made by me!) and the variable is removed from 
variables. But other variables depend on the prefix and so we have an unlimited 
loop.

Possibles fixes:
 - raise an exception if a variable is "bogus"
 - detect loops: ensure that at least was removed during a step (and raise an 
exception if not)
 - keep "bogus" variables (add them to done)

--

___
Python tracker 

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

[issue12071] test_concurrent_futures.test_context_manager_shutdown() hangs on OpenIndiana

[STINNER Victor]

STINNER Victor  added the comment:

Oh, I have "no more memory" errors on this VM especially on fork. 
test_concurrent_futures.test_context_manager_shutdown() failure should be 
related to a memory allocation error. I tried my faulthandler using SIGUSR1 to 
get more information, but send the send does kill the process instead of 
printing the traceback when test_concurrent_futures hangs, whereas it works as 
expected (dump tracebacks) a few tests before...

--

___
Python tracker 

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

[issue12073] regrtest: use faulthandler to dump the tracebacks on SIGUSR1

[STINNER Victor]

New submission from STINNER Victor :

When you run the test suite manually and a test hangs, it would be nice to be 
able to dump immediatly the tracebacks of all threads without having to wait 
the timeout (which is 1 hour by default...).

Attached patch installs a signal handler for the SIGUSR1 signal. So "kill -USR1 
" dumps immedialty the tracebacks without stopping the tests.

I already used it many times. It's useful and I did not notice any failure 
introduced by this change. I tested on Linux, FreeBSD and OpenIndiana. 
faulthandler.register() is not implemented on Windows (which doesn't have 
SIGUSR1 by the way).

I moved also the call to faulthandler.register() into main() to get the same 
behaviour using:
./python Lib/test/regrtest.py ...
./python -m test.regrtest ...
./python -m test ...

Actually, the last one doesn't enable faulthandler.

--
components: Tests
files: regrtest_sigusr1.patch
keywords: patch
messages: 135947
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest: use faulthandler to dump the tracebacks on SIGUSR1
versions: Python 3.3
Added file: http://bugs.python.org/file21995/regrtest_sigusr1.patch

___
Python tracker 

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

[issue6721] Locks in python standard library should be sanitized on fork

[Steffen Daode Nurpmeso]

Steffen Daode Nurpmeso  added the comment:

@ Charles-François Natali  wrote (2011-05-13 
13:24+0200):
> I happily posted a reinit patch

I must say in advance that we have implemented our own thread
support 2003-2005 and i'm thus lucky not to need to use anything
else ever since.  So.  And of course i have no overview about
Python.  But i looked and saw no errors in the default path and
the tests run without errors.
Then i started to try your semaphore path which is a bit
problematic because Mac OS X doesn't offer anon sems ;).
(
By the way, in PyThread_acquire_lock_timed() these lines

if (microseconds > 0)
MICROSECONDS_TO_TIMESPEC(microseconds, ts);

result in these compiler warnings.

python/thread_pthread.h: In function ‘PyThread_acquire_lock_timed’:
Python/thread_pthread.h:424: warning: ‘ts.tv_sec’ may be used
uninitialized in this function
Python/thread_pthread.h:424: warning: ‘ts.tv_nsec’ may be used
uninitialized in this function
)

#ifdef USE_SEMAPHORES
#define broken_sem_init broken_sem_init
static int broken_sem_init(sem_t **sem, int shared, unsigned int value) {
int ret;
auto char buffer[32];
static long counter = 3000;
sprintf(buffer, "%016ld", ++counter);
*sem = sem_open(buffer, O_CREAT, (mode_t)0600, (unsigned int)value);
ret = (*sem == SEM_FAILED) ? -1 : 0;
//printf("BROKEN_SEM_INIT WILL RETURN %d (value=%u)\n", ret,value);
return ret;
}
static int sem_timedwait(sem_t *sem, struct timespec *ts) {
int success = -1, iters = 1000;
struct timespec now, wait;
printf("STARTING LOOP\n");
for (;;) {
if (sem_trywait(sem) == 0) {
printf("TRYWAIT OK\n");
success = 0;
break;
}
wait.tv_sec = 0, wait.tv_nsec = 200 * 1000;
//printf("DOWN "); fflush(stdout);
nanosleep(&wait, NULL);
MICROSECONDS_TO_TIMESPEC(0, now);
//printf("WOKE UP NOW=%ld:%ld END=%ld:%ld\n", now.tv_sec,now.tv_nsec, 
ts->tv_sec,ts->tv_nsec);
if (now.tv_sec > ts->tv_sec ||
(now.tv_sec == ts->tv_sec && now.tv_nsec >= ts->tv_nsec))
break;
if (--iters < 0) {
printf("BREAKING OFF LOOP, 1000 iterations\n");
errno = ETIMEDOUT;
break;
}
}
return success;
}
#define sem_destroy sem_close

typedef struct _pthread_lock {
sem_t   *sem;
struct _pthread_lock*next;
sem_t   sem_buf;
} pthread_lock;
#endif

plus all the changes the struct change implies, say.
Yes it's silly, but i wanted to test.  And this is the result:

== CPython 3.3a0 (default:804abc2c60de+, May 14 2011, 01:09:53) [GCC 4.2.1 
(Apple Inc. build 5666) (dot 3)]
==   Darwin-10.7.0-i386-64bit little-endian
==   /Users/steffen/src/cpython/build/test_python_19230
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, 
dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, 
verbose=0, bytes_warning=0, quiet=0)
Using random seed 1362049
[1/1] test_threading
STARTING LOOP
test_acquire_contended (test.test_threading.LockTests) ... ok
test_acquire_destroy (test.test_threading.LockTests) ... ok
test_acquire_release (test.test_threading.LockTests) ... ok
test_constructor (test.test_threading.LockTests) ... ok
test_different_thread (test.test_threading.LockTests) ... ok
test_reacquire (test.test_threading.LockTests) ... ok
test_state_after_timeout (test.test_threading.LockTests) ... ok
test_thread_leak (test.test_threading.LockTests) ... ok
test_timeout (test.test_threading.LockTests) ... STARTING LOOP
TRYWAIT OK
FAIL
test_try_acquire (test.test_threading.LockTests) ... ok
test_try_acquire_contended (test.test_threading.LockTests) ... ok
test_with (test.test_threading.LockTests) ... ok
test__is_owned (test.test_threading.PyRLockTests) ... ok
test_acquire_contended (test.test_threading.PyRLockTests) ... ok
test_acquire_destroy (test.test_threading.PyRLockTests) ... ok
test_acquire_release (test.test_threading.PyRLockTests) ... ok
test_constructor (test.test_threading.PyRLockTests) ... ok
test_different_thread (test.test_threading.PyRLockTests) ... ok
test_reacquire (test.test_threading.PyRLockTests) ... ok
test_release_unacquired (test.test_threading.PyRLockTests) ... ok
test_thread_leak (test.test_threading.PyRLockTests) ... ok
test_timeout (test.test_threading.PyRLockTests) ... STARTING LOOP
TRYWAIT OK
FAIL
test_try_acquire (test.test_threading.PyRLockTests) ... ok
test_try_acquire_contended (test.test_threading.PyRLockTests) ... ok
test_with (test.test_threading.PyRLockTests) ... ok
test__is_owned (test.test_threading.CRLockTests) ... ok
test_acquire_contended (test.test_threading.CRLockTests) ... ok
test_acquire_destroy (test.test_threading.CRLockTests) ... ok
test_acquire_release (test.test_threading.CRLockTests) ... ok
test_constructor (test.test_threading.CRLockTests) ... ok
test_different_thread (test.test_threading.CRLockTests) ... ok
test_reacquire (test.test_threading

[issue12074] regrtest: display the current number of failures

[STINNER Victor]

New submission from STINNER Victor :

The full test suite has something like 354 tests. regrtest writes one line per 
test, and if you use Python compiled in debug mode you have much more lines 
because of "[123 refs]" lines written by subprocesses.

It's difficult to check if a previous test failed or not. If your terminal has 
a small backlog (e.g. 200 lines), it is maybe just not possible to know. In 
buildbot logs, it is also hard to search the first failure because the log is 
very verbose.

Attached patch adds " -- 1 failure" suffix after the first failure. If you use 
the -j option, the number of failure is written directly (because the test name 
is only printed after the test is done). By default, the counter is incremented 
*after* the failure.

--

Example (I modified test_os to ensure that it fails):

marge$ ./python -m test test_os test_sys test_os test_sys
[1/4] test_os
test test_os crashed -- Traceback (most recent call last):
  File "/home/haypo/prog/HG/cpython/Lib/test/regrtest.py", line 1047, in 
runtest_inner
the_package = __import__(abstest, globals(), locals(), [])
  File "/home/haypo/prog/HG/cpython/Lib/test/test_os.py", line 5, in 
assert 1 == 0
AssertionError

[2/4] test_sys -- 1 failure
[37703 refs]
[37701 refs]
[37954 refs]
[37919 refs]
[3/4] test_os -- 1 failure
test test_os crashed -- Traceback (most recent call last):
  File "/home/haypo/prog/HG/cpython/Lib/test/regrtest.py", line 1047, in 
runtest_inner
the_package = __import__(abstest, globals(), locals(), [])
  File "/home/haypo/prog/HG/cpython/Lib/test/test_os.py", line 5, in 
assert 1 == 0
AssertionError

[4/4] test_sys -- 2 failures
[37703 refs]
[37701 refs]
[37954 refs]
[37919 refs]
2 tests OK.
1 test failed:
test_os
[98160 refs]

--
components: Tests
files: regrtest_failures.patch
keywords: patch
messages: 135949
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest: display the current number of failures
versions: Python 3.3
Added file: http://bugs.python.org/file21996/regrtest_failures.patch

___
Python tracker 

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

[issue12074] regrtest: display the current number of failures

[STINNER Victor]

STINNER Victor  added the comment:

See also issue #12073.

--

___
Python tracker 

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

[issue12073] regrtest: use faulthandler to dump the tracebacks on SIGUSR1

[STINNER Victor]

STINNER Victor  added the comment:

See also issue #12074.

--

___
Python tracker 

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

[issue1475523] gettext breaks on plural-forms header

[Ricky Zhou]

Changes by Ricky Zhou :


--
nosy: +ricky

___
Python tracker 

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

[issue11731] Simplify email API via 'policy' objects

[R. David Murray]

Changes by R. David Murray :


--
resolution:  -> accepted
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

[issue5723] Incomplete json tests

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 5b0fecd2eba0 by Ezio Melotti in branch '2.7':
#5723: Improve json tests to be executed with and without accelerations.
http://hg.python.org/cpython/rev/5b0fecd2eba0

New changeset c2853a54b29e by Ezio Melotti in branch '3.1':
#5723: Improve json tests to be executed with and without accelerations.
http://hg.python.org/cpython/rev/c2853a54b29e

New changeset 63fb2b811c9d by Ezio Melotti in branch '3.2':
#5723: merge with 3.1.
http://hg.python.org/cpython/rev/63fb2b811c9d

New changeset afdc06f2552f by Ezio Melotti in branch 'default':
#5723: merge with 3.2.
http://hg.python.org/cpython/rev/afdc06f2552f

--
nosy: +python-dev

___
Python tracker 

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

[issue5723] Incomplete json tests

[Ezio Melotti]

Changes by Ezio Melotti :


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

[issue12038] assertEqual doesn't display newline differences quite well

[Terry J. Reedy]

Terry J. Reedy  added the comment:

A possible fix is to condense the output by omitting stuff in the center rather 
than as the end:
"x\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx...x\nx\nx\nx\nx\nx\nx\nx\nx\nx\n"
"x\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx...x\nx\nx\nx\nx\nx\nx\nx\nx\nx\r\n"
would be clear.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue7960] test.support.captured_output has invalid docstring example

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 459e2c024420 by Ezio Melotti in branch '2.7':
#7960: fix docstrings for captured_output and captured_stdout.
http://hg.python.org/cpython/rev/459e2c024420

New changeset c2126d89c29b by Ezio Melotti in branch '3.1':
#7960: fix docstrings for captured_output and captured_stdout.
http://hg.python.org/cpython/rev/c2126d89c29b

New changeset 18a192ae6db9 by Ezio Melotti in branch '3.2':
#7960: merge with 3.1.
http://hg.python.org/cpython/rev/18a192ae6db9

New changeset 7517add4aec9 by Ezio Melotti in branch 'default':
#7960: merge with 3.2.
http://hg.python.org/cpython/rev/7517add4aec9

--
nosy: +python-dev

___
Python tracker 

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

[issue7960] test.support.captured_output has invalid docstring example

[Ezio Melotti]

Ezio Melotti  added the comment:

I fixed the docstring, however I think captured_output should be renamed 
_captured_output, since it only works with sys.stdout/in/err and there are 
already 3 other functions (in 3.2/3.3) that use captured_output to replace the 
3 std* streams.  There's no reason to document and use it elsewhere.
Georg, what do you think?

--
resolution:  -> fixed
stage:  -> committed/rejected

___
Python tracker 

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

[issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3" but "10.5" during configure

[Ronald Oussoren]

Changes by Ronald Oussoren :


--
versions:  -Python 3.1

___
Python tracker 

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

[issue11979] Minor improvements to the Sockets readme: typos, wording and sphinx features usage

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 4081f326e46c by Ezio Melotti in branch '2.7':
#11979: improve wording and markup in sockets howto. Patch by Xavier Morel.
http://hg.python.org/cpython/rev/4081f326e46c

New changeset 85b9ad8b219b by Ezio Melotti in branch '3.1':
#11979: improve wording and markup in sockets howto. Patch by Xavier Morel.
http://hg.python.org/cpython/rev/85b9ad8b219b

New changeset bc251b65de1d by Ezio Melotti in branch '3.2':
#11979: merge with 3.1.
http://hg.python.org/cpython/rev/bc251b65de1d

New changeset 4b122cac7ac5 by Ezio Melotti in branch 'default':
#11979: merge with 3.2.
http://hg.python.org/cpython/rev/4b122cac7ac5

--
nosy: +python-dev

___
Python tracker 

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

[issue11979] Minor improvements to the Sockets readme: typos, wording and sphinx features usage

[Ezio Melotti]

Ezio Melotti  added the comment:

Fixed, thanks for the patches!

--
assignee: docs@python -> ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
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

[issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3" but "10.5" during configure

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Attached the backport to 2.7 for my v2 patch.

--
Added file: http://bugs.python.org/file21997/issue9516-v2-python2.7.patch

___
Python tracker 

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

[issue6191] HTMLParser attribute parsing - 2 test cases when it fails

[Ezio Melotti]

Ezio Melotti  added the comment:

What I described in my previous message is what Firefox does.  If you think 
this should be changed, I suggest you to open another issue, possibly attaching 
a test case with the desired behavior and a patch to change it.

--

___
Python tracker 

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

[issue11981] dupe self.fp.tell() in zipfile.ZipFile.writestr

[Ezio Melotti]

Ezio Melotti  added the comment:

I double checked the code on py3k and I think the second occurrence can be 
removed.

--
nosy: +alanmcintyre
versions: +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