[issue6090] zipfile DeprecationWarning Python 2.5/2.6

[anatoly techtonik]

anatoly techtonik  added the comment:

This code is broken in 2.7alpha4 - it doesn't add file at all.

Traceback (most recent call last):
  File "test.py", line 5, in 
new.writestr(zi,'fgh')
  File "C:\~env\Python27\lib\zipfile.py", line 1099, in writestr
self.fp.write(zinfo.FileHeader())
  File "C:\~env\Python27\lib\zipfile.py", line 342, in FileHeader
len(filename), len(extra))
struct.error: ushort format requires 0 <= number <= USHRT_MAX

--
components: +Library (Lib) -Extension Modules
nosy: +techtonik
title: zipfile DeprecationWarning Python 2.6.2 -> zipfile DeprecationWarning 
Python 2.5/2.6
versions: +Python 2.5, Python 2.7
Added file: http://bugs.python.org/file16775/test6090.py

___
Python tracker 

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

[issue6090] zipfile DeprecationWarning Python 2.5/2.6

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti
priority:  -> normal
stage:  -> needs patch
type:  -> behavior
versions:  -Python 2.5

___
Python tracker 

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

[issue8320] docs on socket.recv_into doesn't mention the return value

[Georg Brandl]

Georg Brandl  added the comment:

Thanks, fixed in r79822.

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

[issue2824] zipfile to handle duplicate files in archive

[anatoly techtonik]

anatoly techtonik  added the comment:

Still an issue for Python 2.7

--
versions: +Python 2.7
Added file: http://bugs.python.org/file16776/test2824.py

___
Python tracker 

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

[issue8322] test_ssl failures with OpenSSL 1.0.0

[STINNER Victor]

STINNER Victor  added the comment:

Extract of SSL_CTX_new manual page:


SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)

  A TLS/SSL connection established with these methods will understand
  the SSLv2, SSLv3, and TLSv1 protocol. A client will send out SSLv2
  client hello messages and will indicate that it also understands
  SSLv3 and TLSv1. A server will understand SSLv2, SSLv3, and TLSv1
  client hello messages. This is the best choice when compatibility
  is a concern.

I don't think that "Client protocol SSLv23 succeeded with server protocol 
SSLv3" or "Client protocol SSLv23 succeeded with server protocol TLSv1" are 
errors.

--
nosy: +haypo

___
Python tracker 

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

[issue8322] test_ssl failures with OpenSSL 1.0.0

[Antoine Pitrou]

Antoine Pitrou  added the comment:

It begs the question of why the tests succeed with previous OpenSSL versions.
The only possibly relevant entry I could find in the OpenSSL changelog (but I'm 
not an expert) is the following:

  *) If no SSLv2 ciphers are used don't use an SSLv2 compatible client hello:
 this allows the use of compression and extensions. Change default cipher
 string to remove SSLv2 ciphersuites. This effectively avoids ancient SSLv2
 by default unless an application cipher string requests it.
 [Steve Henson]

--

___
Python tracker 

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

[issue2228] Imaplib speedup patch

[anatoly techtonik]

Changes by anatoly techtonik :


--
components: +Library (Lib)
type: resource usage -> performance
versions: +Python 2.7

___
Python tracker 

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

[issue7772] test_py3kwarn fails when running the whole test suite

[Mark Dickinson]

Mark Dickinson  added the comment:

I very much appreciate flox's efforts here, but IMO we really need some more 
robust solution to the problem of (testing + global warning state).

See also issue 4180.

--

___
Python tracker 

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

[issue8325] improve regrtest command line help

[anatoly techtonik]

New submission from anatoly techtonik :

regrtest command line help can be greatly improved to encourage users run tests.

--
components: Tests
messages: 102443
nosy: techtonik
severity: normal
status: open
title: improve regrtest command line help
versions: Python 2.7

___
Python tracker 

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

[issue8325] improve regrtest command line help

[Eric Smith]

Eric Smith  added the comment:

Any suggestions for what these changes would be?

--
nosy: +eric.smith
stage:  -> needs patch
type:  -> feature request
versions: +Python 3.2

___
Python tracker 

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

[issue7834] socket.connect() no longer works with AF_BLUETOOTH L2CAP sockets

[Yaniv Aknin]

Yaniv Aknin  added the comment:

I wouldn't mind producing the patch, if Mathew is OK with this.

--
nosy: +Yaniv.Aknin

___
Python tracker 

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

[issue8322] test_ssl failures with OpenSSL 1.0.0

[STINNER Victor]

STINNER Victor  added the comment:

All errors concern SSLv23 at server side, and another protocol at client side 
(SSLv23 for client and server works as expected).

--

___
Python tracker 

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

[issue8326] Cannot import name SemLock

[David Coconut]

New submission from David Coconut :

Operating system: Ubuntu 10.04 Lucid Lynx (Beta)

This worked with Python 3.1 on 9.10 Karmic Koala. The same error appears on two 
separate installations of Lucid.

Issue 3770 does not seem to be relevant here.

Traceback (most recent call last):
File "/usr/lib/python3.1/multiprocessing/synchronize.py", line 28, in 
from _multiprocessing import SemLock
ImportError: cannot import name SemLock

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File 
"main.py", line 16, in 
q = JoinableQueue()
File "/usr/lib/python3.1/multiprocessing/__init__.py", line 218, in 
JoinableQueue
from multiprocessing.queues import JoinableQueue

File "/usr/lib/python3.1/multiprocessing/queues.py", line 22, in 
from multiprocessing.synchronize import Lock, BoundedSemaphore, Semaphore, 
Condition

File "/usr/lib/python3.1/multiprocessing/synchronize.py", line 33, in 
" function, see issue 3770.")

ImportError: This platform lacks a functioning sem_open implementation, 
therefore, the required synchronization primitives needed will not function, 
see issue 3770.

--
messages: 102447
nosy: coconutrb
severity: normal
status: open
title: Cannot import name SemLock
type: crash
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

[issue8325] improve regrtest command line help

[anatoly techtonik]

anatoly techtonik  added the comment:

This should be enough for now. Is HG diff against trunk ok?

--
keywords: +patch
versions: +Python 2.6
Added file: http://bugs.python.org/file16777/8325.improve-regrtest-help.diff

___
Python tracker 

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

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ok, here is a patch fixing all test_ftplib failures (tested with openssl 0.9.8k 
and 1.0.0).
There are a couple of fixes here:
- a workaround for the strange SSL_shutdown() error return, also witnessed by 
LightHTTPd users (see URL in comments)
- an auto-retry for SSLSocket.unwrap() in blocking mode
- a bizarre issue in test_ftplib where DTPHandler.handle_close() gets called 
many times in a test (test_data_connection)

I think the SSL_shutdown() issue should be checked on the OpenSSL mailing-list.

--

___
Python tracker 

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

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

[Antoine Pitrou]

Changes by Antoine Pitrou :


Added file: http://bugs.python.org/file16778/newssl.patch

___
Python tracker 

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

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

def handle_error(self):
-raise
+# Ignore errors while closing, because the remote end could have
+# abruptly shut down the TCP connection while we are still
+# waiting for SSL shutdown to finish.
+if not self._ssl_closing:
+raise


I don't like this.
I should have said that I think my original patch is wrong as it attempts to 
shutdown() the SSL layer in asyncore's close() method.
I think that I should have done that in handle_close() instead of close() 
because the two methods are called in different circumstances and have 
different meanings:

- handle_close() is supposed to be called when the connection is a about to be 
closed "in a clean way" (for example: the other end properly finished to 
transmit all the data).

- close() may be called in different situations, also when the connection gets 
closed abruptly. In this case we should avoid to shutdown() the SSL layer as we 
might be dealing with a "dead" connection. The right thing to do in this case 
is just close() the socket without doing anything else.

IMHO, what we should try to avoid to do here is silently ignoring any error 
condition as you did in handle_error() method.
What happens if you move the SSL shutdown() call in handle_close() method and 
leave handle_error() unchanged?

--

___
Python tracker 

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

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> What happens if you move the SSL shutdown() call in handle_close()
> method and leave handle_error() unchanged?

I get occasional crashes such as the following:

Exception in thread Thread-60:
Traceback (most recent call last):
  File "/home/antoine/cpython/newssl/Lib/threading.py", line 530, in 
__bootstrap_inner
self.run()
  File "/home/antoine/cpython/newssl/Lib/test/test_ftplib.py", line 229, in run
asyncore.loop(timeout=0.1, count=1)
  File "/home/antoine/cpython/newssl/Lib/asyncore.py", line 211, in loop
poll_fun(timeout, map)
  File "/home/antoine/cpython/newssl/Lib/asyncore.py", line 154, in poll
write(obj)
  File "/home/antoine/cpython/newssl/Lib/asyncore.py", line 88, in write
obj.handle_error()
  File "/home/antoine/cpython/newssl/Lib/asyncore.py", line 84, in write
obj.handle_write_event()
  File "/home/antoine/cpython/newssl/Lib/test/test_ftplib.py", line 313, in 
handle_write_event
super(SSLConnection, self).handle_write_event()
  File "/home/antoine/cpython/newssl/Lib/asyncore.py", line 440, in 
handle_write_event
self.handle_write()
  File "/home/antoine/cpython/newssl/Lib/asynchat.py", line 174, in handle_write
self.initiate_send()
  File "/home/antoine/cpython/newssl/Lib/asynchat.py", line 215, in 
initiate_send
self.handle_close()
  File "/home/antoine/cpython/newssl/Lib/test/test_ftplib.py", line 352, in 
handle_close
self._do_ssl_shutdown()
  File "/home/antoine/cpython/newssl/Lib/test/test_ftplib.py", line 290, in 
_do_ssl_shutdown
self.socket.unwrap()
  File "/home/antoine/cpython/newssl/Lib/ssl.py", line 264, in unwrap
s = self._sslobj.shutdown()
error: [Errno 32] Broken pipe

--

___
Python tracker 

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

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

[Antoine Pitrou]

Antoine Pitrou  added the comment:

By the way, this "broken pipe" error could be due to the fact that the
FTP_TLS client never tries to call unwrap() on its SSL socket. Perhaps
the close() method should be overriden?

--

___
Python tracker 

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

[issue1572968] release GIL while doing I/O operations in the mmap module

[Charles-Francois Natali]

Charles-Francois Natali  added the comment:

As soon as you're dealing with files (not anonymous mapping), you can get the 
same type of latency than when using open/read/write...
While it's probably not worth the trouble to release the GIL for every 
operation involving mmaped-files, there are a couple places where it should be 
considered, for example:
Modules/mmapmodule.c:new_mmap_object
#ifdef HAVE_FSTAT
#  ifdef __VMS
/* on OpenVMS we must ensure that all bytes are written to the file */
if (fd != -1) {
fsync(fd);
}
#  endif

fsync() can take up to a couple seconds, so we should probably allow threads 
here (this is done only on VMS).
Another place worth looking at is when using msync(), like in 
mmap_object_dealloc():
if (m_obj->data!=NULL) {
msync(m_obj->data, m_obj->size, MS_SYNC);
munmap(m_obj->data, m_obj->size);
}

or in mmap_flush_method():
if (-1 == msync(self->data + offset, size, MS_SYNC)) {
PyErr_SetFromErrno(mmap_module_error);
return NULL;
}

msycn too can take quite a long time to complete.

I can write a patch if someone's willing to review it.

--
nosy: +neologix

___
Python tracker 

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

[issue8325] improve regrtest command line help

[Eric Smith]

Eric Smith  added the comment:

That diff format looks fine to me. I'll review the content of your changes in 
the next day or so.

--
keywords: +easy, needs review
priority:  -> normal
stage: needs patch -> patch review

___
Python tracker 

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

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is a new patch. It doesn't change handle_error() but instead ignores 
abruptly closed sockets when doing the SSL shutdown.

The underlying problem seems to be an asyncore limitation: close() can be 
called after an error such as EPIPE or ECONNABORTED, but asyncore doesn't give 
us any way to know in advance.

--
Added file: http://bugs.python.org/file16779/newssl2.patch

___
Python tracker 

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

[issue8312] Add post/pre hooks for distutils commands

[Zubin Mithra]

Changes by Zubin Mithra :


--
nosy: +zubin71

___
Python tracker 

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

[issue8324] add a distutils test command

[Zubin Mithra]

Changes by Zubin Mithra :


--
nosy: +zubin71

___
Python tracker 

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

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

> By the way, this "broken pipe" error could be due to the fact that the
> FTP_TLS client never tries to call unwrap() on its SSL socket. Perhaps
> the close() method should be overriden?

ftplib.FTP_TLS class already calls unwrap() but only when closing a "secured" 
*data* connection.
This is never done for the *control* connection as the examples shown in 
RFC-4217 do that only when dealing with the CCC command which is intended to 
switch the control connection back to clear text.
Since ftplib.py does not implement the CCC command I would avoid to override 
its close() method.

As for our test server we are currently shutting down the SSL layer for both 
connections (control and data) so this might be the cause of EPIPE.
At this proposal I suggest to move the shutdown() call from 
SSLConnection.handle_close() to DummyTLS_DTPHandler.handle_close() and see what 
happens.
If EPIPE keeps being raised then I would investigate on what EPIPE means in 
terms of OpenSSL itself. It might mean that the socket is supposed to be closed 
in which case it's perfectly legitimate.

I'd have a few questions:

> a workaround for the strange SSL_shutdown() error return, also
> witnessed by LightHTTPd users (see URL in comments)

What happens now? I mean... what do we get instead of socket.error: 0?

> an auto-retry for SSLSocket.unwrap() in blocking mode

Wasn't SSL_MODE_AUTO_RETRY option applied in issue 8222 supposed to already do 
that for us?

> I think the SSL_shutdown() issue should be checked on the OpenSSL 
> mailing-list.

If socket.error: 0 comes from OpenSSL then yes. I was suspecting something like 
this.

--

___
Python tracker 

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

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> As for our test server we are currently shutting down the SSL layer for
> both connections (control and data) so this might be the cause of EPIPE.

I don't understand your reasoning. These are separate connections, closing one 
shouldn't affect the other.

> At this proposal I suggest to move the shutdown() call from
> SSLConnection.handle_close() to DummyTLS_DTPHandler.handle_close() and 
> see what happens.

What happens is that you are taking shortcuts with SSL since you aren't trying 
to do a proper shutdown :)
If you really think this is a good idea, feel free to give it a try.
But please see newssl2.patch as well.

(of course this is only a test server but AFAIU you would like to make it right)

> What happens now? I mean... what do we get instead of socket.error: 0?

A normal successful return.

> Wasn't SSL_MODE_AUTO_RETRY option applied in issue 8222 supposed to 
> already do that for us?

SSL_MODE_AUTO_RETRY deals with SSL negotiation. SSL_shutdown() has its own 
separate semantics, which have changed *even in blocking mode*. If I disable 
auto-retry I get failures such as:

==
ERROR: test_storbinary (test.test_ftplib.TestTLS_FTPClassMixin)
--
Traceback (most recent call last):
  File "/home/antoine/cpython/newssl/Lib/test/test_ftplib.py", line 505, in 
test_storbinary
self.client.storbinary('stor', f)
  File "/home/antoine/cpython/newssl/Lib/ftplib.py", line 727, in storbinary
conn.unwrap()
  File "/home/antoine/cpython/newssl/Lib/ssl.py", line 264, in unwrap
s = self._sslobj.shutdown()
SSLError: [Errno 2] _ssl.c:1374: The operation did not complete (read)

(note how "the operation did not complete" seems to mean that the socket is 
non-blocking, but the error is happening with the regular blocking FTP client)

--
versions:  -Python 2.6, Python 3.1

___
Python tracker 

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

[issue8326] Cannot import name SemLock

[R. David Murray]

R. David Murray  added the comment:

Why do you think issue 3770 is not relevant?  It looks from the traceback like 
the built version of multiprocessing decided that sem_open wasn't functional.  
So this sounds like a lucid packaging problem to me.

--
components: +Extension Modules
nosy: +r.david.murray
priority:  -> normal
type: crash -> behavior

___
Python tracker 

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

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

> I don't understand your reasoning. These are separate connections, 
> closing one shouldn't affect the other.

I meant another thing. I was talking about the fact that the test server 
attempts to shutdown() both control and data connections while the client only 
shutdown() the latter one. Maybe that's why you get EPIPE.

> If you really think this is a good idea, feel free to give it a try.

I whish but I'm having serious setup problems problems because I attempted to 
install different OpenSSL versions and now I'm no longer able to compile Python.
Anyway, I'll give another try later today. =)

> But please see newssl2.patch as well.

- ftplib.FTP_TLS.quit: I wouldn't call unwrap() here as RFC-4217 does that only 
when dealing with CCC command which is not implemented by ftplib.py.

- I'd be for calling _do_ssl_shutdown() from handle_close() instead of from 
close() (reasons explained in my previous message)

- If EPIPE is still raised I'd try to move the shutdown() code from 
SSLConnection.handle_close() to DummyTLS_DTPHandler.handle_close().

--

___
Python tracker 

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

[issue8326] Cannot import name SemLock on Ubuntu lucid

[R. David Murray]

R. David Murray  added the comment:

I'm guessing Matthias might have some insight into this on the Ubuntu side. so 
I'm adding him as nosy.  I'm thinking this isn't a Python problem, but I could 
be wrong.

--
nosy: +doko
title: Cannot import name SemLock -> Cannot import name SemLock on Ubuntu lucid

___
Python tracker 

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

[issue6090] zipfile DeprecationWarning Python in 2.6, failure in 2.7

[R. David Murray]

R. David Murray  added the comment:

Making the stage test needed, since we need to get the test into the test suite 
as a unit test.

--
nosy: +r.david.murray
stage: needs patch -> test needed
title: zipfile DeprecationWarning Python 2.5/2.6 -> zipfile DeprecationWarning 
Python in 2.6, failure in 2.7

___
Python tracker 

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

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> - ftplib.FTP_TLS.quit: I wouldn't call unwrap() here as RFC-4217 does
> that only when dealing with CCC command which is not implemented by
> ftplib.py.

Ok.

> - I'd be for calling _do_ssl_shutdown() from handle_close() instead of
> from close() (reasons explained in my previous message)

This provokes test failures such as:

==
ERROR: test_dir (test.test_ftplib.TestTLS_FTPClassMixin)
--
Traceback (most recent call last):
  File "/home/antoine/cpython/newssl/Lib/test/test_ftplib.py", line 537, in 
test_dir
self.client.dir(lambda x: l.append(x))
  File "/home/antoine/cpython/newssl/Lib/ftplib.py", line 511, in dir
self.retrlines(cmd, func)
  File "/home/antoine/cpython/newssl/Lib/ftplib.py", line 714, in retrlines
return self.voidresp()
  File "/home/antoine/cpython/newssl/Lib/ftplib.py", line 224, in voidresp
resp = self.getresp()
  File "/home/antoine/cpython/newssl/Lib/ftplib.py", line 210, in getresp
resp = self.getmultiline()
  File "/home/antoine/cpython/newssl/Lib/ftplib.py", line 196, in getmultiline
line = self.getline()
  File "/home/antoine/cpython/newssl/Lib/ftplib.py", line 183, in getline
line = self.file.readline()
  File "/home/antoine/cpython/newssl/Lib/socket.py", line 445, in readline
data = self._sock.recv(self._rbufsize)
  File "/home/antoine/cpython/newssl/Lib/ssl.py", line 98, in 
self.recv = lambda buflen=1024, flags=0: SSLSocket.recv(self, buflen, flags)
  File "/home/antoine/cpython/newssl/Lib/ssl.py", line 217, in recv
return self.read(buflen)
  File "/home/antoine/cpython/newssl/Lib/ssl.py", line 138, in read
return self._sslobj.read(len)
SSLError: The read operation timed out

I have already tested quite a bunch of possibilities (handle_close or
close, silencing EPIPE or not...)

> - If EPIPE is still raised I'd try to move the shutdown() code from
> SSLConnection.handle_close() to DummyTLS_DTPHandler.handle_close().

This only makes the server less respectful of the protocol...
I think it is fine to silence EPIPE and friends during SSL shutdown
since, as I've said, asyncore will call handle_close() when the remote
ends has closed the TCP connection.

--

___
Python tracker 

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

[issue8297] AttributeError message text should include module name

[Ray.Allen]

Ray.Allen  added the comment:

This patch makes the AttributeError message generated from getting attributes 
from module object more helpful, that is, print the module name. Now the error 
message is:
  module object 'mod_name' has no attribute 'xxx'
Instead of:
  'module' object has no attribute 'xxx'

In this patch, I add a function PyObject_GenericFindAttr(), which is almost the 
same as PyObject_GenericGetAttr(), except that return NULL instead of setting 
the exception, and make PyObject_GenericGetAttr() call this function and 
setting exception in the case of NULL return value. Through this, each type can 
custom its own AttributeError message, while using the uniform process of 
getting the attribute in PyObject_GenericFindAttr(). For example, 
PyModuleType's tp_getattro is set to a new function PyModule_GetAttr(), which 
calls the PyObject_GenericFindAttr() can set the customed AttributeError 
message.

Besides, I think the super object's AttributeError message should also be 
improved, but I didn't include that in the patch. I don't know weather it is 
suitable.

--
keywords: +patch
Added file: http://bugs.python.org/file16780/issue_8297.diff

___
Python tracker 

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

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

[Antoine Pitrou]

Antoine Pitrou  added the comment:

New patch without the quit() method change.

--
Added file: http://bugs.python.org/file16781/newssl3.patch

___
Python tracker 

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

[issue1572968] release GIL while doing I/O operations in the mmap module

[Antoine Pitrou]

Antoine Pitrou  added the comment:

This shouldn't really care about VMS here. As for the rest, feel free to 
propose a patch :)
Please note that most non-trivial system calls, such as ftruncate(), mremap(), 
even mmap() itself, deserve to be enclosed in 
Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS pairs.

However, you'll have to be careful that the internal state of the mmap object 
remains consistent, such that using it from several threads doesn't crash the 
interpreter.
(you can even add multi-threaded unit tests if you want to be sure of this)

--

___
Python tracker 

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

[issue1572968] release GIL while doing I/O operations in the mmap module

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> This shouldn't really care about VMS here.

Correction: /we/ shouldn't really care about VMS here.
And the reason being, of course, that we have neither developers nor
known testers under VMS.
(we don't even know if the current trunk builds there or not)

--

___
Python tracker 

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

[issue1572968] release GIL while doing I/O operations in the mmap module

[Brian Curtin]

Changes by Brian Curtin :


--
nosy: +brian.curtin

___
Python tracker 

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

[issue8188] Unified hash for numeric types.

[Stefan Krah]

Stefan Krah  added the comment:

I've finished reviewing the patch and I think it's quite ready to be
applied.

The documentation in stdtypes.rst says that P = 2**61-1 on 64-bit
machines. This should be changed to reflect the fact that actually
sizeof long is the deciding factor. I attach a patch that also fixes
the typo pointed out by Christophe Simonis.

--
Added file: http://bugs.python.org/file16782/doc_stdtypes.patch

___
Python tracker 

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

[issue6090] zipfile DeprecationWarning Python in 2.6, failure in 2.7

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
priority: normal -> critical

___
Python tracker 

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

[issue8257] Decimal constructor to accept float

[Mark Dickinson]

Mark Dickinson  added the comment:

The decimal changes were implemented by Raymond in r79609 (trunk) and r79602 
(py3k).  For the fractions module changes, see issue 8294.

--
assignee: mark.dickinson -> 
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

[issue8322] test_ssl failures with OpenSSL 1.0.0

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue5198] Strange DeprecationWarning behaviour in module struct

[Mark Dickinson]

Mark Dickinson  added the comment:

The wrong location for the DeprecationWarnings was also fixed in trunk in 
r78690.  I've backported the fix to release26-maint in r79834.

I don't dare mess further with the warnings in a bugfix release;  as Georg 
points out, the issues are fixed in trunk.  BTW, one of the 2.6 issues (again 
fixed in trunk) that wasn't mentioned above is that some packs produce *two* 
overflow-related warnings:

>>> import struct
>>> struct.pack('

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

[issue8014] Setting a T_INT attribute raises internal error

[Mark Dickinson]

Mark Dickinson  added the comment:

Backported to 3.1 in r79838.

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

[issue8293] HTTPSConnection.close() does not immediately close the connection.

[David Andrzejewski]

David Andrzejewski  added the comment:

Now, it turns out that if you send the HTTP "Connection: close" header, the 
connection does close at the end (because the server closes it).

Still, it seems like this should behave the same regardless of whether it's 
HTTPConnection or HTTPSConnection.

--

___
Python tracker 

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

[issue7834] socket.connect() no longer works with AF_BLUETOOTH L2CAP sockets

[Mathew Martineau]

Mathew Martineau  added the comment:

Yaniv - Please proceed!

--

___
Python tracker 

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

[issue8259] left shift operator doesn't accepts long as second argument

[Mark Dickinson]

Mark Dickinson  added the comment:

Patch that unoutrages Python attached:  it allows shift counts of up to 
sys.maxsize in both left shift and right shift.  I don't have a test for this, 
since the only tests I can think of (e.g. actually doing 1 << (2**31)) require 
> 270Mb of RAM, and that may be too much for some of the buildbots.  (We could 
add a 'largemem' special resource to regrtest, I suppose, but it doesn't seem 
worth the effort just for this.)

This patch doesn't solve the OPs problem, though.  The PyLong code *could* be 
modified to accept larger shift counts (e.g., up to 8*PY_SSIZE_T_MAX;  beyond 
this you'll get a MemoryError anyway), but this seems like a significant effort 
for little gain.  It might make more sense for right shifting, though.  Anyway, 
I'd definitely call that a feature request.

--
assignee:  -> mark.dickinson
keywords: +patch
Added file: http://bugs.python.org/file16783/no_outrage.patch

___
Python tracker 

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

[issue7834] socket.connect() no longer works with AF_BLUETOOTH L2CAP sockets

[Antoine Pitrou]

Antoine Pitrou  added the comment:

By the way, even better if you find a way of having unit tests for bluetooth 
sockets. Is there some kind of "dummy" device which gives predictable results 
(à la /dev/zero, for example)?

--

___
Python tracker 

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

[issue8259] left shift operator doesn't accepts long as second argument

[Mark Dickinson]

Mark Dickinson  added the comment:

Patch applied in r79843 (and added forgotten Misc/NEWS entry in r79844);  
merged to py3k in r79845.

--
assignee: mark.dickinson -> 
type:  -> feature request

___
Python tracker 

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

[issue8193] test_zlib fails with zlib 1.2.4

[Mike Kelly]

Changes by Mike Kelly :


--
nosy: +pioto

___
Python tracker 

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

[issue1553375] Add traceback.print_full_exception()

[Pascal Chambon]

Pascal Chambon  added the comment:

What's the status of this (imo quite useful) new traceback function ?
Shall I provide some help ?

--

___
Python tracker 

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

[issue8327] unintuitive behaviour of logging message propagation

[Pascal Chambon]

New submission from Pascal Chambon :

Hello

Crawling into the logging module, I've just discovered its behaviour was 
actually far from the one I expected, in a consequent gap that the 
documentation had left.

I thought that depending on the "propagate" parameter of each logger, a message 
would always try to propagate up the logger hierarchy, and that if that message 
matched the level of a logger (as well as the global disable() level), then 
this message would be tested against each handler of that logger.

But it's not at all the way it is : actually, only the level of the "entrance" 
logger is checked ; if the message is blocked by it, it's the end, parent 
loggers will never hear about it (even thoiugh they might have a lower level 
set). On the contrary, if that entrance logger accepts the message, then ALL 
handlers from the hierarchy are snet the message, without caring about the own 
level of their related logger.

That's really not the behaviour I would have expected, considering the 
global_disable > logger_level > handler_level precedence that the doc 
implicitly showed. Are there rationales behind this that I'm lacking ?

So I'd advocate either (if possible) a patching of the logging system, to 
reflect that semantic ; or the adding of comprehensive paragraphs to teh doc, 
to explain what the exact relationship between levels and propagation 
attribuets are.
Just tell me if a patch is conceivable B-)

--
components: Library (Lib)
messages: 102477
nosy: pakal
severity: normal
status: open
title: unintuitive behaviour of logging message propagation
versions: Python 2.7

___
Python tracker 

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

[issue8193] test_zlib fails with zlib 1.2.4

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Committed in r79848 (trunk), r79849 (py3k), r79850 (2.6), r79851 (3.1). Thank 
you!

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

[issue8327] unintuitive behaviour of logging message propagation

[Eric Smith]

Changes by Eric Smith :


--
nosy: +eric.smith

___
Python tracker 

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

[issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt

[Andrey Vlasovskikh]

Andrey Vlasovskikh  added the comment:

Despite of several workarounds available on the Web, the problem persists. 
Almost any exception that is rised in `worker` function while putting or 
getting tasks from queues result in Pool hang up. Currently, `worker` is only 
aware of Exception descendants rised inside of the map function parameter.

I've written a unit test that checks if KeyboardInterrupts are handled 
normally. The source code may be included in `Lib/test/test_multiprocessing.py`.

--
Added file: http://bugs.python.org/file16784/test_map_keyboard_interrput.py

___
Python tracker 

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

[issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt

[Andrey Vlasovskikh]

Changes by Andrey Vlasovskikh :


Removed file: http://bugs.python.org/file16743/test_pool_keyboardinterrupt.py

___
Python tracker 

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

[issue8259] left shift operator doesn't accepts long as second argument

[Mark Dickinson]

Mark Dickinson  added the comment:

By the way, this has nothing to do with int versus long (unless I'm 
misunderstanding the original issue);  it's simply that large shift counts 
cause an OverflowError.

I've added a note about this to the docs in r79852.

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

[issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt

[Andrey Vlasovskikh]

Andrey Vlasovskikh  added the comment:

Here is a patch that fixes this problem. Basically, it catches all the 
BaseExceptions that could happen during: a) getting a task from the `inqueue`, 
b) calling a user function, c) putting a task into the `outqueue`. The 
exception handler puts the exception to the `outqueue`.

It can be cleanly applied on top of revision 78790.

--
keywords: +patch
Added file: http://bugs.python.org/file16785/fix-sigint.diff

___
Python tracker 

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

[issue8328] longobject.c: silence warnings (Visual Studio)

[Stefan Krah]

New submission from Stefan Krah :

Mark, are you ok with silencing these conversion warnings?

--
components: Build
files: longobject_vs_warnings_py3k.patch
keywords: patch
messages: 102482
nosy: mark.dickinson, skrah
severity: normal
status: open
title: longobject.c: silence warnings (Visual Studio)
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16786/longobject_vs_warnings_py3k.patch

___
Python tracker 

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

[issue8328] longobject.c: silence warnings (Visual Studio)

[Stefan Krah]

Changes by Stefan Krah :


Added file: http://bugs.python.org/file16787/longobject_vs_warnings_trunk.patch

___
Python tracker 

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

[issue8328] longobject.c: silence warnings (Visual Studio)

[Mark Dickinson]

Mark Dickinson  added the comment:

These all look fine to me.  Please apply!

--
assignee:  -> skrah
resolution:  -> accepted

___
Python tracker 

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

[issue8327] unintuitive behaviour of logging message propagation

[Vinay Sajip]

Vinay Sajip  added the comment:

Please see the following link for a rationale of the logging package's design:

http://plumberjack.blogspot.com/2009/09/python-logging-101.html

No patch to the logging system's code is planned, as it is working according to 
its design. The documentation will be gradually attended to as time allows, and 
patches will be considered.

--
assignee:  -> vinay.sajip
components: +Documentation -Library (Lib)
nosy: +vinay.sajip

___
Python tracker 

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

[issue8193] test_zlib fails with zlib 1.2.4

[Valerio Turturici]

Valerio Turturici  added the comment:

Thanks to you! This was my first patch, i'm very happy to contribute :)

--

___
Python tracker 

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

[issue7947] Documentation of math.pow, math.hypot, and complex.__abs__

[Mark Dickinson]

Mark Dickinson  added the comment:

Proposed update to math docs.

--
keywords: +patch
Added file: http://bugs.python.org/file16788/math_docs.patch

___
Python tracker 

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

[issue7947] Documentation of math.pow, math.hypot, and complex.__abs__

[Georg Brandl]

Georg Brandl  added the comment:

Looks good to me.  Is it intentional that the paragraph about signaling NaNs is 
gone completely?

And is it intentional that you changed behavior -> behaviour? :)

--

___
Python tracker 

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

[issue7947] Documentation of math.pow, math.hypot, and complex.__abs__

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks, Georg.

Yes and No.

Yes:  Perhaps I should say something about signaling nans, but what was there 
was just nonsense.

No:  I'll drop the 'u' from behaviour, for the sake of consistency.

--

___
Python tracker 

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

[issue7947] Documentation of math.pow, math.hypot, and complex.__abs__

[Georg Brandl]

Georg Brandl  added the comment:

You don't need to :)

--

___
Python tracker 

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

[issue7947] Documentation of math.pow, math.hypot, and complex.__abs__

[Mark Dickinson]

Mark Dickinson  added the comment:

Too late!  Committed in r79858 (trunk) through r79861 (release31-maint).
I added a couple of sentences about signaling nans.

Thanks for reviewing!

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

___
Python tracker 

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

[issue7947] Documentation of math.pow, math.hypot, and complex.__abs__

[Georg Brandl]

Georg Brandl  added the comment:

You didn't give me the chance to review the new sentences!  Now I have to tell 
you that there is now "NaN", "*NaN*" and "nan" which looks inconsistent... :)

--

___
Python tracker 

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

[issue7472] email.encoders.encode_7or8bit(): typo "iso-2202". "iso-2022" is correct.

[Shashwat Anand]

Shashwat Anand  added the comment:

I am submitting the patch as suggested by Yukihiro

--
keywords: +patch
nosy: +l0nwlf
Added file: http://bugs.python.org/file16789/encoders.diff

___
Python tracker 

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

[issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt

[Brian Curtin]

Changes by Brian Curtin :


--
nosy: +jnoller

___
Python tracker 

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

[issue7472] email.encoders.encode_7or8bit(): typo "iso-2202". "iso-2022" is correct.

[R. David Murray]

R. David Murray  added the comment:

Well, as I said, I think it would be better to delete the conditional instead.  
(That is, that fixing the typo is more likely to lead to a bug).

--
assignee: barry -> r.david.murray

___
Python tracker 

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

[issue1303434] Please include pdb with windows distribution

[Chris Grebeldinger]

Chris Grebeldinger  added the comment:

Hi Martin,
  As an aside to the request, is the pdb for the python dll currently available 
anywhere?

--
nosy: +cgrebeld

___
Python tracker 

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

[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows

[Charles-Francois Natali]

Charles-Francois Natali  added the comment:

I don't think that calling msync() or FlushViewOfFile() when closing the mmap 
object or deallocating it is a good idea.
sync()ing dirtied pages to disk is very expensive, blocks the process for a 
long time, and the OS does a much better job at it (it can be done 
asynchronously, sync()ing can be grouped, re-ordered, etc).
For example, it took around 7 seconds to msync() a mmap-filed of 300Mb in a 
quick test I've done.
Furthermore, we don't do this for regular files: when a file object is closed 
or deallocated, we don't call fsync(), and the documentation makes it clear:

os.fsync(fd)
Force write of file with filedescriptor fd to disk. On Unix, this calls the 
native fsync() function; on Windows, the MS _commit() function.

If you’re starting with a Python file object f, first do f.flush(), and then do 
os.fsync(f.fileno()), to ensure that all internal buffers associated with f are 
written to disk. Availability: Unix, and Windows starting in 2.2.3.

The reason is the same: fsync(), like msync(), is not usually what you want, 
because of latencies and performance penalties it incurs.
Any application requiring the data to be actually written to disk _must_ call 
fsync() for file objects, and call the flush() method of mmap objects (which is 
done just for that reason).

So, for performance and consistency with files, I'd suggest to remove calls to 
msync() and FlushViewOfFile() from close() and dealloc().
If agreed, I can submit the patch.

> A test could explicitly close a dirtied mmaped file and then open()
> it to check that everything was written, no?

The problem is that when you open() your file, you'll read the data from cache. 
You have no way to read the data directly from disk (well, there may be, but 
are higly non portable, like O_DIRECT file or raw IO).
The only check that can be done is tracing the process and checking that 
msync() is indeed called.

--
nosy: +neologix

___
Python tracker 

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

[issue8329] select.select() can return lists with identical id()'s

[Mike Kent]

New submission from Mike Kent :

If select.select() returns two or more empty lists, these empty lists will all 
refer to the same list; that is, they will have identical id()'s.  If you then 
have reason to alter one of the returned empty lists, you are altering all of 
the returned empty lists.  This can result in some significant debugging time 
spent, and curse words uttered.

I encountered this in Python 2.5.4, but have not yet verified it on a more 
recent version.  Searching through the Issue Tracker showed nothing similar.

--
components: Library (Lib)
messages: 102496
nosy: mrmakent
severity: normal
status: open
title: select.select() can return lists with identical id()'s
versions: Python 2.5

___
Python tracker 

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

[issue8329] select.select() can return lists with identical id()'s

[Mike Kent]

Changes by Mike Kent :


--
type:  -> behavior

___
Python tracker 

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

[issue4570] Bad example in set tutorial

[Kelda]

Kelda  added the comment:

Replaced unused variable assignment with a call to set() for illustrative 
purposes.

--
keywords: +patch
nosy: +autometa
Added file: http://bugs.python.org/file16790/datastructures.diff

___
Python tracker 

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

[issue8329] select.select() can return lists with identical id()'s

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Fixed in r79867.

--
nosy: +benjamin.peterson
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

[issue7947] Documentation of math.pow, math.hypot, and complex.__abs__

[Mark Dickinson]

Mark Dickinson  added the comment:

Rats.

nan->NaN in r79871 through r79874.

Then I reread your message...

*NaN* -> Nan in r79875 (trunk);  will merge to other branches tomorrow when my 
brain might be working again.

--
status: closed -> open

___
Python tracker 

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

[issue8299] Improve GIL in 2.7

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

I just did some profiling.  I´m using visual studio team edition which has some 
fancy built in profiling.  I decided to compare the performance of the 
iotest.py script with two cpu threads, running for 10 seconds with processor 
affinity enabled and disabled.  I added this code to the script:
if affinity:
import ctypes
i = ctypes.c_int()
i.value = 1
ctypes.windll.kernel32.SetProcessAffinityMask(-1, 1)

Regular instruction counter sampling showed no differences.  There were no 
indications of excessive time being used in the GIL or any strangeness with the 
locking primitives.  So, I decided to sample on cpu performance counters.  
Following up on my conjecture from yesterday, that this was due to 
inefficiencies in switching between cpus, I settled on sampling the instruction 
fetch stall cycles from the instruction fetch unit.  I sample every 100 
stalls.  I get interesting results.

With affinity:
Functions Causing Most Work
NameSamples %
_PyObject_Call  403 99,02
_PyEval_EvalFrameEx 402 98,77
_PyEval_EvalCodeEx  402 98,77
_PyEval_CallObjectWithKeywords  400 98,28
call_function   395 97,05

affinity off:
Functions Causing Most Work
NameSamples %
_PyEval_EvalFrameEx 1.937   99,28
_PyEval_EvalCodeEx  1.937   99,28
_PyEval_CallObjectWithKeywords  1.936   99,23
_PyObject_Call  1.936   99,23
_threadstartex  1.934   99,13

When we run on both cores, we get four times as many L1 instruction cache hits! 
 So, what appears to be happening is that each time that a switch occurs the L1 
instruction cache for each core must be repopulated with the python evaluation 
loop, it having been evacuated on that core during the hiatus.

Note that for this effect to kick in we need a large piece of code excercising 
the cache, such as the evaluation loop.  Earlier today, I wrote a simple 
(python free) C program to do similar testing, using a GIL, and found no 
performance degradation due to multi core, but that program only had a very 
simple "work" function.

So, this confirms my hypothesis:  The downgrading of the performance of python 
cpu bound threads on multicore machines stems from the shuttling about of the 
python evaluation loop between the instruction caches of the individual cores.

How best to combat this?  I'll do some experiments on Windows.  Perhaps we can 
identify cpu-bound threads and group them on a single core.

--

___
Python tracker 

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

[issue8327] unintuitive behaviour of logging message propagation

[Vinay Sajip]

Vinay Sajip  added the comment:

Documentation updated (r79876).

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

[issue8299] Improve GIL in 2.7

[Antoine Pitrou]

Antoine Pitrou  added the comment:

[...]
> _PyObject_Call403 99,02
[...]
> affinity off:
> Functions Causing Most Work
> Name  Samples %
[...]
> _PyObject_Call1.936   99,23
[...]
> _threadstartex1.934   99,13
> 
> When we run on both cores, we get four times as many L1 instruction cache 
> hits!

You mean we get 4x the number of cache /misses/, right?

This analysis is gratuitous if you can't evaluate/measure/calculate the
actual cost (in proportion of total elapsed or CPU time) of the
instruction cache misses. Perhaps it is actually negligible and the
slowdown is caused by something else.

> How best to combat this?  I'll do some experiments on Windows.
> Perhaps we can identify cpu-bound threads and group them on a single
> core.

IMHO, the OS should handle this. I don't think ad-hoc platform-specific
CPU affinity tweaks belong in the Python core.

--

___
Python tracker 

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

[issue8324] add a distutils test command

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +merwok

___
Python tracker 

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

[issue8312] Add post/pre hooks for distutils commands

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +merwok

___
Python tracker 

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

[issue1303434] Please include pdb with windows distribution

[Martin v . Löwis]

Martin v. Löwis  added the comment:

>   As an aside to the request, is the pdb for the python dll currently 
> available anywhere?

Only on my hard disk, and then only for the very last release. The
status of the issue is the same as in 2006: without patches, nothing
will happen.

--

___
Python tracker 

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

[issue7301] Add environment variable $PYTHONWARNINGS

[Philip Jenvey]

Philip Jenvey  added the comment:

Looks good to me. Updated patch with a couple whitespace changes

--
Added file: http://bugs.python.org/file16791/issue7301-2.diff

___
Python tracker 

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

[issue7301] Add environment variable $PYTHONWARNINGS

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

Patch looks good to me too.  Do any of you have commit privileges?  If so, 
please commit this.  If not assign the issue to me and I'll do it.

--
resolution:  -> accepted

___
Python tracker 

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

[issue8299] Improve GIL in 2.7

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

The counter is "stall cycles".
During the 10 second run on my 2.4Ghz cpu, we had instruction cache miss stalls 
for 2 billion cycles (2000 samples of 100 cycles per sample).  That does 
account for around 10% of the availible cpu.

I'm observing something like 20% slowdown, though, so there are probably other 
causes.

Profiling another counter, "instruction fetches", I see this, for a "fast run":
Functions Causing Most Work
NameSamples %
Unknown Frame(s)10.733  99,49

and for a slow run:
Functions Causing Most Work
NameSamples %
Unknown Frame(s)8.056   99,48

This shows a 20% drop in fetched instructions in the interval (five seconds 
this time).  Ideally, we should see 12000 samples in the fast case (2.4 ghz, 
5s) but we see 1 due to what cache misses there are in this case.  The 
cache misses in the "slow" case causes effective instruction fetches to drop by 
20% on top of that.

I think that this is proof positive that the slowdown is due to instruction 
cache misses, at least on this dual core intel machine that I am using.

As for "the OS should handle this", I agree.  But it doesn't.  We are doing 
something unusual:  Convoying two (or more) threads allowing only one to run at 
a time.  The OS scheduler isn't built for that.  It can only assume that there 
will be some parallel execution and so it thinks that it is best to put the two 
sequential threads on different cpus.  But it is wrong, so the cost associated 
with cache misses outweighs the benefit of running on another core (zero, in 
our case).

So, the OS won't handle it, no matter how hard we wish that it would.  It is us 
that know how these gridlocked threads behave, and we do so much better than 
any OS scheduler can guess.  So, rather than beat our heads against the rock, 
I'm going to try to come up with a useful heuristic as to when to switch cores, 
and when not.  It would be useful as a diagnostic tool, if nothing more.

Ok, so we have established two things, I think:
1) the poor response of IO threads in the presence of CPU threads on 
thread_pthreads.h implementations (on multicore) is because of greedy gil wait 
semantics in the current gil.  It's easily fixable by using the implementation 
ROUNDROBIN_GIL implementation I've shown.
2) The poor performance of competing CPU threads on multicore machines is due 
to the instruction cache behaviour of non-overlapping thread execution on 
different cores.

We can fix 1) easily, even with a much less invasive patch than the ones I have 
put in here.  I'm a bit surprised at the apparent disinterest in such an 
obvious bug / fix.

As for 2), well, see above.  Nothing we can do, really, except identify those 
cases where we are releasing GIL just to yield (one case, actually, ceval.c) 
and try to instruct the OS not to switch cores in that case.  I'll see what I 
can come up with.

Cheers.

--

___
Python tracker 

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

[issue8299] Improve GIL in 2.7

[David Beazley]

David Beazley  added the comment:

The analysis of instruction cache behavior is interesting---I could definitely 
see that coming into play given the heavy penalty that one sees going to 
multiple cores (it's a side effect in addition everything else that goes wrong 
such as a huge increase in the number of system calls).

I will only point out that messing around with processor affinities is going to 
be problematic.  There are C/C++ extensions to Python that intentionally 
release the GIL and want to run fully multithreaded across as many cores as 
might be available.  Setting a processor affinities is going to be the exact 
opposite of what you want for code like that.

--

___
Python tracker 

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

[issue8299] Improve GIL in 2.7

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> The counter is "stall cycles".
> During the 10 second run on my 2.4Ghz cpu, we had instruction cache
> miss stalls for 2 billion cycles (2000 samples of 100 cycles per
> sample).  That does account for around 10% of the availible cpu.

Ok, thanks.

> 2) The poor performance of competing CPU threads on multicore machines
> is due to the instruction cache behaviour of non-overlapping thread
> execution on different cores.

Have you tried your measurement approach with ccbench?

> We can fix 1) easily, even with a much less invasive patch than the
> ones I have put in here.  I'm a bit surprised at the apparent
> disinterest in such an obvious bug / fix.

As already said, it's too late for 2.7. And the fix in 3.2 is most
probably better.

--

___
Python tracker 

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

[issue8330] Failures seen in test_gdb on buildbots

[Dave Malcolm]

New submission from Dave Malcolm :

http://www.python.org/dev/buildbot/trunk/builders/alpha%20Debian%20trunk/builds/52/steps/test/logs/stdio
shows some failures in test_gdb:

==
FAIL: test_corrupt_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a corrupt ob_type is handled gracefully
--
Traceback (most recent call last):
  File 
"/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_gdb.py", 
line 361, in test_corrupt_ob_type
'set op->ob_type=0xDEADBEEF')
  File 
"/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_gdb.py", 
line 341, in assertSane
(gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: '< at remote 0x1202cf5a8>'
Breakpoint 1 at 0x12007a9e8: file Objects/object.c, line 330.
[Thread debugging using libthread_db enabled]

Breakpoint 1, PyObject_Print (op=42, fp=0x22f87b0, flags=1)
at Objects/object.c:330
330 return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=< at remote 0x1202cf5a8>, fp=0x22f87b0, flags=1)
at Objects/object.c:330
#1  0x00012003eaa0 in file_PyObject_Print (op=< at remote 0x1202cf5a8>, f=
0x2326280, flags=1) at Objects/fileobject.c:110
#2  0x000120045bc8 in PyFile_WriteObject (v=< at remote 0x1202cf5a8>, f=
, flags=1) at Objects/fileobject.c:2470
#3  0x00012010bb90 in PyEval_EvalFrameEx (f=
Frame 0x1203a0ba0, for file , line 1, in  (), throwflag=0)
at Python/ceval.c:1769
#4  0x0001201134bc in PyEval_EvalCodeEx (co=0x120305880, globals=
{'__builtins__': , '__name__': '__main__', 
'__doc__': None, '__package__': None}, locals=
{'__builtins__': , '__name__': '__main__', 
'__doc__': None, '__package__': None}, args=0x0, argcount=0, kws=0x0, 
kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#5  0x000120107294 in PyEval_EvalCode (co=0x120305880, globals=
{'__builtins__': , '__name__': '__main__', 
'__doc__': None, '__package__': None}, locals=
{'__builtins__': , '__name__': '__main__', 
'__doc__': None, '__package__': None}) at Python/ceval.c:666
#6  0x000120152e08 in run_mod (mod=0x12038b848, filename=
0x12021cf00 "", globals=
{'__builtins__': , '__name__': '__main__', 
'__doc__': None, '__package__': None}, locals=
{'__builtins__': , '__name__': '__main__', 
'__doc__': None, '__package__': None}, flags=0x11f48b4d8, arena=0x1203406b0)
at Python/pythonrun.c:1340
#7  0x000120152c2c in PyRun_StringFlags (str=0x1202b2010 "print 42\n", 
start=257, globals=
{'__builtins__': , '__name__': '__main__', 
'__doc__': None, '__package__': None}, locals=
{'__builtins__': , '__name__': '__main__', 
'__doc__': None, '__package__': None}, flags=0x11f48b4d8)
at Python/pythonrun.c:1303
#8  0x000120150f50 in PyRun_SimpleStringFlags (command=
0x1202b2010 "print 42\n", flags=0x11f48b4d8) at Python/pythonrun.c:962
#9  0x0001200185a0 in Py_Main (argc=4, argv=0x11f48b6b8)
at Modules/main.c:525
#10 0x000120016e88 in main (argc=4, argv=0x11f48b6b8)
at ./Modules/python.c:23


==
FAIL: test_corrupt_tp_name (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_name is handled
--
Traceback (most recent call last):
  File 
"/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_gdb.py", 
line 372, in test_corrupt_tp_name
'set op->ob_type->tp_name=0xDEADBEEF')
  File 
"/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_gdb.py", 
line 341, in assertSane
(gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: '42'
Breakpoint 1 at 0x12007a9e8: file Objects/object.c, line 330.
[Thread debugging using libthread_db enabled]

Breakpoint 1, PyObject_Print (op=42, fp=0x22f87b0, flags=1)
at Objects/object.c:330
330 return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=42, fp=0x22f87b0, flags=1) at Objects/object.c:330
#1  0x00012003eaa0 in file_PyObject_Print (op=42, f=0x2326280, flags=1)
at Objects/fileobject.c:110
#2  0x000120045bc8 in PyFile_WriteObject (v=42, f=
, flags=1) at Objects/fileobject.c:2470
#3  0x00012010bb90 in PyEval_EvalFrameEx (f=
Frame 0x1203a0ba0, for file , line 1, in  (), throwflag=0)
at Python/ceval.c:1769
#4  0x0001201134bc in PyEval_EvalCodeEx (co=0x120305880, globals=
{'__builtins__': , '__name__': '__main__', 
'__doc__': None, '__package__': None}, locals=
{'__builtins__': , '__name__': '__main__', 
'__doc__': None, '__package__': None}, args=0x0, argcount=0, kws=0x0, 
kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#5  0x000120107294 in PyEval_EvalCode (co=0x120305880, globals=
{'__builtin

[issue8331] a documentation grammar fix in logging module

[Shashwat Anand]

New submission from Shashwat Anand :

Just fixed some grammatical error in the docs of logging module.

--
assignee: georg.brandl
components: Documentation
files: logging.patch
keywords: patch
messages: 102510
nosy: georg.brandl, l0nwlf, vinay.sajip
severity: normal
status: open
title: a documentation grammar fix in logging module
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16792/logging.patch

___
Python tracker 

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

[issue4487] Add utf8 alias for email charsets

[Shashwat Anand]

Shashwat Anand  added the comment:

I tested it on python 2.5, 2.6, 2.7 trunk and 3.2 varying msg.set_charset(x) 
with x = 'utf8' and 'utf-8' 
Here are the results. Apparantly python 2.x had issue with Test case and 3.2 
passed but I guess it is unrelated with the issue.

07:35:40 l0nwlf-MBP:~ $ python2.5
Python 2.5.4 (r254:67916, Jul  7 2009, 23:51:24) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from email.MIMEText import MIMEText
>>> msg = MIMEText(u'\u043a\u0438\u0440\u0438\u043b\u0438\u0446\u0430')
>>> msg.set_charset('utf8')
>>> print msg.as_string()
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/message.py",
 line 131, in as_string
g.flatten(self, unixfrom=unixfrom)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/generator.py",
 line 84, in flatten
self._write(msg)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/generator.py",
 line 109, in _write
self._dispatch(msg)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/generator.py",
 line 135, in _dispatch
meth(msg)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/generator.py",
 line 178, in _handle_text
self._fp.write(payload)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-7: 
ordinal not in range(128)
>>> msg.set_charset('utf-8')
>>> print msg.as_string()
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/message.py",
 line 131, in as_string
g.flatten(self, unixfrom=unixfrom)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/generator.py",
 line 84, in flatten
self._write(msg)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/generator.py",
 line 109, in _write
self._dispatch(msg)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/generator.py",
 line 135, in _dispatch
meth(msg)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/email/generator.py",
 line 178, in _handle_text
self._fp.write(payload)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-7: 
ordinal not in range(128)

07:36:17 l0nwlf-MBP:~ $ python2.6
Python 2.6.5 (r265:79063, Apr  6 2010, 21:34:21) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from email.MIMEText import MIMEText
>>> msg = MIMEText(u'\u043a\u0438\u0440\u0438\u043b\u0438\u0446\u0430')
>>> msg.set_charset('utf8')
>>> print msg.as_string()
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/message.py",
 line 135, in as_string
g.flatten(self, unixfrom=unixfrom)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/generator.py",
 line 84, in flatten
self._write(msg)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/generator.py",
 line 109, in _write
self._dispatch(msg)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/generator.py",
 line 135, in _dispatch
meth(msg)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/generator.py",
 line 178, in _handle_text
self._fp.write(payload)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-7: 
ordinal not in range(128)
>>> msg.set_charset('utf-8')
>>> print msg.as_string()
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/message.py",
 line 135, in as_string
g.flatten(self, unixfrom=unixfrom)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/generator.py",
 line 84, in flatten
self._write(msg)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/generator.py",
 line 109, in _write
self._dispatch(msg)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/generator.py",
 line 135, in _dispatch
meth(msg)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/email/generator.py",
 line 178, in _handle_text
self._fp.write(payload)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-7: 
ordinal not in range(128)
 
07:36:37 l0nwlf-MBP:~ $ python2.7
Python 2.7a4+ (trunk:78750, Mar  7 2010, 08:09:00) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> f

[issue4570] Bad example in set tutorial

[John Marter]

John Marter  added the comment:

You may want to add another space before the comment, otherwise it will be the 
only one not aligned with the others.

--

___
Python tracker 

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

[issue4570] Bad example in set tutorial

[Shashwat Anand]

Shashwat Anand  added the comment:

I guess giving fruit, the set of unique fruit a different name makes it more 
clear. Comments alignment fixed.

>>> basket = {'apple', 'orange', 'apple', 'pear', 'orange', 'banana'}
>>> print(basket)
{'orange', 'bananna', 'pear', 'apple'}
>>> fruit = ['apple', 'orange', 'apple', 'pear', 'orange', 'banana']
>>> uniquefruit = set(fruit)   # create a set without duplicates
>>> uniquefruit
{'orange', 'pear', 'apple', 'banana'}

--
nosy: +l0nwlf
Added file: http://bugs.python.org/file16793/datastructure.patch

___
Python tracker 

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

[issue8331] a documentation grammar fix in logging module

[Ezio Melotti]

Changes by Ezio Melotti :


--
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> normal
resolution:  -> accepted
stage:  -> patch review

___
Python tracker 

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

[issue8297] AttributeError message text should include module name

[Chris Jerdonek]

Chris Jerdonek  added the comment:

Great -- thanks a lot for taking a stab at this!

--

___
Python tracker 

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

[issue7301] Add environment variable $PYTHONWARNINGS

[Philip Jenvey]

Philip Jenvey  added the comment:

applied in r79878 - r79881, thanks!

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

[issue8271] str.decode('utf8', 'replace') -- conformance with Unicode 5.2.0

[Ezio Melotti]

Ezio Melotti  added the comment:

The patch was causing a failure in test_codeccallbacks, issue8271v4 fixes the 
test.
(The failing test in test_codeccallbacks was testing that registering error 
handlers works, using a function that replaced "\xc0\x80" with "\x00". Since 
now "\xc0" is an invalid start byte regardless of what follows, the function is 
now receiving only "\xc0" instead of "\xc0\x80" so I had to change the test.)

--
keywords: +needs review
Added file: http://bugs.python.org/file16794/issue8271v4.diff

___
Python tracker 

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

[issue4570] Bad example in set tutorial

[Kelda]

Kelda  added the comment:

I think this change fits well with the rest of the example without having to 
rework things.  Spacing fixed.

--
Added file: http://bugs.python.org/file16795/datastructures.diff

___
Python tracker 

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

[issue8297] AttributeError message text should include module name

[Chris Jerdonek]

Changes by Chris Jerdonek :


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

[issue4570] Bad example in set tutorial

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I'll get to this soon.

--

___
Python tracker 

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