[issue7503] multiprocessing AuthenticationError "digest sent was rejected" when pickling proxy

[Pete Hunt]

Pete Hunt  added the comment:

UPDATE: this example WORKS if you remove "authkey" - so it seems to be a 
problem with authentication.

--
type:  -> crash

___
Python tracker 

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

[issue6472] Inconsistent use of "iterator" in ElementTree doc & diff between Py and C modules

[flox]

flox  added the comment:

Small update of the patch for 3.2: the __cmp__method is replaced with
__eq__ method (on CommentProxy and PIProxy).

--
Added file: http://bugs.python.org/file15552/issue6472_upstream_py3k_v2.diff

___
Python tracker 

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

[issue6472] Inconsistent use of "iterator" in ElementTree doc & diff between Py and C modules

[flox]

Changes by flox :


Removed file: http://bugs.python.org/file15471/issue6472_upstream_py3k.diff

___
Python tracker 

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

[issue6472] Inconsistent use of "iterator" in ElementTree doc & diff between Py and C modules

[flox]

Changes by flox :


Removed file: http://bugs.python.org/file15513/issue6472_upstream_docs.diff

___
Python tracker 

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

[issue6472] Inconsistent use of "iterator" in ElementTree doc & diff between Py and C modules

[flox]

Changes by flox :


Added file: http://bugs.python.org/file15553/issue6472_upstream_docs.diff

___
Python tracker 

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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Laszlo (Laca) Peter]

Changes by Laszlo (Laca) Peter :


--
nosy: +laca

___
Python tracker 

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

[issue7475] codecs missing: base64 bz2 hex zlib ...

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Martin v. Löwis wrote:
> 
> Martin v. Löwis  added the comment:
> 
>> So, after reading the above comments, I think we may end up with
>> following changes:
>>  * restore the "bytes-to-bytes" codecs in the "encodings" package

+1

>>  * then create new helpers on bytes objects (either
>>".transform()/.untransform()" or ".encodebytes()/.decodebytes")

+1 - the names are still up for debate, IIRC.

> I would still be opposed to such a change, and I think it needs a PEP.

All this has already been discussed and the only reason it didn't
go in earlier was timing. No need for a PEP.

> If the codecs are restored, one half of them becomes available to
> .encode/.decode methods, since the codec registry cannot tell which
> ones implement real character encodings, and which ones are other
> conversion methods. So adding them would be really confusing.

Not at all. The helper methods check the return types and raise an
exception if the types don't match the expected types.

The codecs registry itself doesn't need to know about the possible
input/output types of codecs, since this information is not
required to match a name to an implementation.

What we could do, is add that information to the CodecInfo object
used for registering the codec. codecs.lookup() would then
return the information to the application.

E.g.

.encode_input_types = (str,)
.encode_output_types = (bytes,)
.decode_input_types = (bytes,)
.decode_output_types = (str,)

Codecs not supporting these CodecInfo attributes would simply
return None.

> I also wonder why you are opposed to the import statement. My
> recommendation is indeed that you use the official API for these
> libraries (and indeed, there is an official API for each of them,
> unlike real codecs, which don't have any other documented API).

That's not the point. The codec API provides a standardized API for
all these encodings. The hex, zlib, bz2, etc. codecs are just
adapters of the different pre-existing APIs to the codec API.

--

___
Python tracker 

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

[issue7503] multiprocessing AuthenticationError "digest sent was rejected" when pickling proxy

[R. David Murray]

Changes by R. David Murray :


--
nosy: +jnoller

___
Python tracker 

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

[issue7503] multiprocessing AuthenticationError "digest sent was rejected" when pickling proxy

[R. David Murray]

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

[issue7504] Same name cookies

[Andrey Chichak]

New submission from Andrey Chichak :

After setting cookies with same name and different path only nearest to 
root cookie is available.

Attached patch:
1. Set Cookie to nearest value.
2. Collects all same name values in Cookie._multi[''] in 
order.

--
components: Library (Lib)
files: Cookie.py.diff
keywords: patch
messages: 96375
nosy: chch
severity: normal
status: open
title: Same name cookies
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file15554/Cookie.py.diff

___
Python tracker 

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

[issue4757] reject unicode in zlib

[flox]

flox  added the comment:

Definitely, zlib.compress should raise a TypeError (like bz2 does).

>>> import bz2, zlib
>>> bz2.compress('abc')
Traceback (most recent call last):
  File "", line 1, in 
TypeError: argument 1 must be bytes or buffer, not str
>>> zlib.compress('abc')
b"x\x9cKLJ\x06\x00\x02M\x01'"

Someone can review the patch and merge it?

--
nosy: +flox
versions: +Python 3.2 -Python 3.0

___
Python tracker 

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

[issue2259] Poor support other than 44.1khz, 16bit audio files?

[R. David Murray]

Changes by R. David Murray :


--
assignee: r.david.murray -> 

___
Python tracker 

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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I'm not sure there's any real issue here. The signal *does* get
propagated to the main thread, it only takes some time to do so. If you
want the program to be interruptible more quickly, just lower the
timeout you give to select().

--

___
Python tracker 

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

[issue4757] reject unicode in zlib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The patch lacks a test that TypeError is raised on unicode input,
otherwise it's fine.

--

___
Python tracker 

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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

I don't like the suggestion to lower the timeout to select().  Lots of
the rest of the world is pushing towards removing this kind of periodic
polling (generally with the goal of improving power consumption). 
Python should be going this way too (the recent introduction of
signal.set_wakeup_fd suggests that at least some Python developers are
convinced of this).

--
nosy: +exarkun

___
Python tracker 

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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I don't like the suggestion to lower the timeout to select().  Lots of
> the rest of the world is pushing towards removing this kind of periodic
> polling (generally with the goal of improving power consumption). 

Yes, I'm aware of this. I was only suggesting the easiest solution to
the problem at hand :-)

--

___
Python tracker 

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

[issue1680159] Misleading exception from unicode.__contains__

[R. David Murray]

R. David Murray  added the comment:

Committed in r76831.  (I changed the test assertion to check
specifically for UnicodeDecodeError.)

--

___
Python tracker 

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

[issue4757] reject unicode in zlib

[flox]

flox  added the comment:

Patch from haypo updated for r76830 .

Additional tests for TypeError, and to check that bytearray objects are
accepted.

--
Added file: http://bugs.python.org/file1/issue4757_zlib_bytes.diff

___
Python tracker 

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

[issue4757] reject unicode in zlib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The patch produces a number of errors in test_tarfile, test_distutils,
test_gzip and test_xmlrpc.

--

___
Python tracker 

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

[issue4757] reject unicode in zlib

[flox]

flox  added the comment:

Fixed.

And some "bytearray" tests improved in test_zlib.

--
Added file: http://bugs.python.org/file15556/issue4757_zlib_bytes_v2.diff

___
Python tracker 

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

[issue7505] ctypes not converting None to Null in 64-bit system

[Venkateswaran]

New submission from Venkateswaran :

The attached code is failing to convert None to Null. It is successful 
if the int* is shifted towards the beginning of argument list. The bug 
is actually in 32/64 bit pointers as the code works on a 32 bit system.

The bug disappears if I reduce the number of arguments to less than 10.

I created the so using the command - "gcc  -shared -fPIC  -o libtest.so 
libtest.c", (gcc (Debian 4.3.2-1.1) 4.3.2) 

The c file is as follows:

libtest.c
#include 
#include 


int32_t where ( int32_t a, int32_t c, int32_t d, int32_t e, int32_t f, 
int32_t g, int32_t h, int32_t *b, int32_t i, int32_t j, int32_t k, 
int32_t l)
{
printf("b = %p\n", (void *)b);
printf("a = %d, c = %d, d = %d, e = %d, f = %d, g = %d, h = %d, i = 
%d, j = %d, k = %d,  l = %d", a,c,d,e,f,g,h,i,j,k,l);

return 100;

} /* where() */

Python Code:
import ctypes

libtest = ctypes.CDLL('./libtest.so')
where = libtest.where
where.restype = ctypes.c_int
where.argtypes = [ 
ctypes.c_int32, ctypes.c_int32, ctypes.c_int32,  
ctypes.c_int32, ctypes.c_int32, ctypes.c_int32, ctypes.c_int32,
ctypes.POINTER(ctypes.c_int32),
ctypes.c_int32, ctypes.c_int32, ctypes.c_int32, 
ctypes.c_int32,
 ]


a = 7
b = None

status = where(a,a,a,a,a,a,a,b,a,a,a,a)

--
assignee: theller
components: ctypes
files: test.py
messages: 96385
nosy: theller, wenkat_s
severity: normal
status: open
title: ctypes not converting None to Null in 64-bit system
type: crash
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file15557/test.py

___
Python tracker 

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

[issue4757] reject unicode in zlib

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
assignee:  -> pitrou
resolution:  -> accepted

___
Python tracker 

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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Adam Olsen]

Adam Olsen  added the comment:

The real, OS signal does not get propagated to the main thread.  Only
the python-level signal handler runs from the main thread.

Correctly written programs are supposed to let select block
indefinitely.  This allows them to have exactly 0 CPU usage, especially
important on laptops and other limited power devices.

--

___
Python tracker 

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

[issue7119] email: msg.items() returns different values before and after msg.as_string()

[R. David Murray]

R. David Murray  added the comment:

Here's a doc patch.

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

___
Python tracker 

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

[issue1680159] Misleading exception from unicode.__contains__

[R. David Murray]

Changes by R. David Murray :


--
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> The real, OS signal does not get propagated to the main thread.  Only
> the python-level signal handler runs from the main thread.

Well, the signals /are/ delivered as far as Python code is concerned. I
don't think Python makes any promise as to the delivery of signals at
the C level.
(actually, the best promise we may make is not to block signal delivery
at all, so that third-party libs or extensions relying on threaded
signal delivery don't break)

--

___
Python tracker 

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

[issue4757] reject unicode in zlib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The patch was committed to py3k and 3.1. Thank you!

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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Adam Olsen]

Adam Olsen  added the comment:

You forget that the original report is about ctrl-C.  Should we abandon
support of it for threaded programs?  Close as won't-fix?

We could also just block SIGINT, but why?  That means we don't support
python signal handlers in threaded programs (signals sent to the
process, not ones sent direct to threads), and IMO threads expecting a
specific signal should explicitly unblock it anyway.

--

___
Python tracker 

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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> You forget that the original report is about ctrl-C.  Should we abandon
> support of it for threaded programs?

We haven't abandoned support, have we? Where is the spec that is
currently broken?

Besides, as Jean-Paul pointed out, the user can now setup a file
descriptor on which a byte will be written out as soon as a signal gets
caught.

> Close as won't-fix?

It is one possibility indeed.
We could also add an API (or an optional argument to the existing APIs)
to block signals in threads created by Python.

--

___
Python tracker 

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

[issue7506] multiprocessing.managers.BaseManager.__reduce__ references BaseManager.from_address

[Pete Hunt]

New submission from Pete Hunt :

BaseManager.__reduce__ references from_address, which, to my knowledge, 
has been eliminated from the package.

--
components: Library (Lib)
messages: 96392
nosy: peterhunt
severity: normal
status: open
title: multiprocessing.managers.BaseManager.__reduce__ references 
BaseManager.from_address
type: behavior
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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[John Levon]

John Levon  added the comment:

The spec broken is here:

http://docs.python.org/library/signal.html

Namely:

# Some care must be taken if both signals and threads are used in the
same program. The fundamental thing to remember in using signals and
threads simultaneously is: always perform signal() operations in the
main thread of execution. Any thread can perform an alarm(),
getsignal(), pause(), setitimer() or getitimer(); only the main thread
can set a new signal handler, and the main thread will be the only one
to receive signals (this is enforced by the Python signal module, even
if the underlying thread implementation supports sending signals to
individual threads). This means that signals can’t be used as a means of
inter-thread communication. Use locks instead.

--

___
Python tracker 

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

[issue4770] binascii module, crazy error messages, unexpected behavior

[flox]

flox  added the comment:

I agree, we need consistency between all functions of this package.

I've run a small script to check what happens for all 16 functions of
the binascii package when they receive unicode input...

See attached script (and sample output).

IMHO 4 functions should be fixed to raise the same TypeError:
 - a2b_hex
 - a2b_qp
 - unhexlify
 - rledecode_hqx 

Documentation says that the functions in `binary` module « convert
between binary and various ASCII-encoded binary representations »
So... it's all binary.

Implicit encoding should not happen, never.

--
nosy: +flox
versions: +Python 3.1, Python 3.2 -Python 3.0
Added file: http://bugs.python.org/file15559/case_binascii.py

___
Python tracker 

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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> The spec broken is here:
> 
> http://docs.python.org/library/signal.html

I would argue it is not broken. This documentation page is about a
module of the standard library, it doesn't specify the underlying C
implementation. That "the main thread will be the only one to receive
signals" is true if you consider it from the Python code's point of
view: signal handlers are always called in the main thread, even if the
OS-level signal was delivered to (and caught by) another thread.

I don't have any strong view over whether the interpreter should,
theoretically, block signals in non-main threads. But, practically,
blocking signals apparently produced issues with readline (and possibly
other libs relying on signals), which is why they are not blocked today.

--

___
Python tracker 

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

[issue4757] reject unicode in zlib

[flox]

Changes by flox :


Removed file: http://bugs.python.org/file1/issue4757_zlib_bytes.diff

___
Python tracker 

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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Marcin Stepnicki]

Marcin Stepnicki  added the comment:

> I don't have any strong view over whether the interpreter should,
> theoretically, block signals in non-main threads. But, practically,
> blocking signals apparently produced issues with readline (and possibly
> other libs relying on signals), which is why they are not blocked today.

I see your point of view, but the problem is that current behaviour is
inconsistent between different operating system. As there are many
people who brought up this issue, I think it should be at least
documented somewhere.

Regards,
Marcin

--

___
Python tracker 

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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl
versions: +Python 3.2 -Python 2.4, Python 2.5, Python 3.0

___
Python tracker 

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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

> > http://docs.python.org/library/signal.html

> I would argue it is not broken.

If it's not broken, then the docs are at least confusing.  They should
make clear whether they are talking about the underlying signal or the
Python signal handler.  This makes a difference for many applications
which deal with signals.  I would even say that due to the very tricky
nature of signals, the documentation *should* be discussing the way it
is implemented.  Without that information, it's very difficult to handle
some situations correctly.  This wouldn't necessarily mean that the
implementation would have to stay the same, either - just that the
implementation be documented for each version (of course, keeping it the
same would be preferable, for all the normal reasons).

--

___
Python tracker 

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

[issue7506] multiprocessing.managers.BaseManager.__reduce__ references BaseManager.from_address

[R. David Murray]

R. David Murray  added the comment:

See also issue 5862 and issue 3518.  One or more of these three tickets
could possibly be closed as duplicates.

--
assignee:  -> jnoller
keywords: +easy
nosy: +jnoller, r.david.murray
priority:  -> normal
stage:  -> needs patch

___
Python tracker 

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

[issue7506] multiprocessing.managers.BaseManager.__reduce__ references BaseManager.from_address

[R. David Murray]

Changes by R. David Murray :


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

[issue4770] binascii module, crazy error messages, unexpected behavior

[flox]

flox  added the comment:

This patch removes implicit encoding in binascii functions:
 - a2b_hex (=unhexlify)
 - a2b_qp
 - rledecode_hqx 

 * Tests module "test_binascii" is reviewed and simplified.
 * Fixes for "email", "pickle" and "quopri" modules to encode input.

All tests pass.

--
keywords: +patch
Added file: http://bugs.python.org/file15560/issue4770_binascii_py3k.diff

___
Python tracker 

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

[issue6560] socket sendmsg(), recvmsg() methods

[David Watson]

David Watson  added the comment:

Hi, I'm afraid there may have been some duplication of effort
here - I set about reworking Heiko Wundram's original patch
(issue #1194378) without knowing about this one.  I don't have
unit tests yet either, but I saw this and thought I'd better post
what I had.  It includes the items on Kalman's to-do list.

This patch is based on Heiko's original code, but changes the
interface, dropping the special processing of SCM_RIGHTS, etc. (I
think the encoding/decoding would be better handled with separate
functions/classes), and adds source address (msg_name) support
and scatter/gather I/O via sendmsg() and a new recvmsg_into()
method, as well as fixing various bugs and limitations.

Comments/flames welcome too.  You'll see a few XXX comments in
the code.  One in particular refers to the msg_name value from
recvmsg() on a connected socket; I've said in the docstring that
it is "unspecified" in this case, but it might or might not
contain a valid address, depending on the OS.  These methods may
also need to be conditionally compiled if, say, CMSG_SPACE (or
sendmsg/recvmsg?) isn't available somewhere.

I didn't add a facility to receive into only part of a buffer in
recvmsg_into(), like the one in recv_into(), since memoryview
objects make it redundant AFAICT.

--
nosy: +baikie
Added file: http://bugs.python.org/file15561/baikie-hwundram.diff

___
Python tracker 

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

[issue4770] binascii module, crazy error messages, unexpected behavior

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

flox wrote:
> 
> flox  added the comment:
> 
> This patch removes implicit encoding in binascii functions:
>  - a2b_hex (=unhexlify)
>  - a2b_qp
>  - rledecode_hqx 
> 
>  * Tests module "test_binascii" is reviewed and simplified.
>  * Fixes for "email", "pickle" and "quopri" modules to encode input.
> 
> All tests pass.

Are you sure that this patch is correct (which RFC says
that quoted printable should use our raw-unicode-escape
codec ?):

Index: Lib/email/message.py
===
--- Lib/email/message.py(revision 76839)
+++ Lib/email/message.py(working copy)
@@ -198,6 +198,8 @@
 return None
 cte = self.get('content-transfer-encoding', '').lower()
 if cte == 'quoted-printable':
+if isinstance(payload, str):
+payload = payload.encode('raw-unicode-escape')
 return utils._qdecode(payload)
 elif cte == 'base64':
 try:

The patch also needs to fix the documentation and add a NEWS
entry.

Making these APIs strict in the sense that they don't accept
str-instances anymore needs to be mentioned very clearly.

We may even have to go through a deprecation process for them,
since they can easily cause perfectly working code to suddenly
fail.

--
nosy: +lemburg

___
Python tracker 

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

[issue4770] binascii module, crazy error messages, unexpected behavior

[flox]

flox  added the comment:

> Are you sure that this patch is correct (which RFC says
> that quoted printable should use our raw-unicode-escape
> codec ?):

I am not sure of anything. It is an "educated guess" at the most.
Since 'base64' and 'x-uuencode' both use 'raw-unicode-escape'...

See longer excerpt below.


Index: Lib/email/message.py
===
--- Lib/email/message.py(revision 76839)
+++ Lib/email/message.py(working copy)
@@ -189,24 +189,26 @@
 elif not isinstance(self._payload, list):
 raise TypeError('Expected list, got %s' % type(self._payload))
 else:
 payload = self._payload[i]
 if not decode:
 return payload
 # Decoded payloads always return bytes.  XXX split this part
out into
 # a new method called .get_decoded_payload().
 if self.is_multipart():
 return None
 cte = self.get('content-transfer-encoding', '').lower()
 if cte == 'quoted-printable':
+if isinstance(payload, str):
+payload = payload.encode('raw-unicode-escape')
 return utils._qdecode(payload)
 elif cte == 'base64':
 try:
 if isinstance(payload, str):
 payload = payload.encode('raw-unicode-escape')
 return base64.b64decode(payload)
 #return utils._bdecode(payload)
 except binascii.Error:
 # Incorrect padding
 pass
 elif cte in ('x-uuencode', 'uuencode', 'uue', 'x-uue'):
 in_file = BytesIO(payload.encode('raw-unicode-escape'))

--

___
Python tracker 

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

[issue4770] binascii module, crazy error messages, unexpected behavior

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

flox wrote:
> 
> flox  added the comment:
> 
>> Are you sure that this patch is correct (which RFC says
>> that quoted printable should use our raw-unicode-escape
>> codec ?):
> 
> I am not sure of anything. It is an "educated guess" at the most.
> Since 'base64' and 'x-uuencode' both use 'raw-unicode-escape'...

Quoted printable as well as the other two transfer encodings should
be encodings that "fit" into the 7-bit ASCII default originally
assumed for email messages, so 'ascii' appears to be the more
natural choice.

The choice of 'raw-unicode-escape' will cause strange error
messages or hide errors, since it encodes non-ASCII code points
using '\xNN' which these codecs don't supports:

b''
>>> base64.b64decode('äöü'.encode('ascii'))
Traceback (most recent call last):
  File "", line 1, in 
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: 
ordinal not in range(128)

--

___
Python tracker 

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

[issue4770] binascii module, crazy error messages, unexpected behavior

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I agree with Marc-André that enforcing ASCII looks like the only
sensible solution. Perhaps Barry knows the purpose of using
"raw-unicode-escape" here, though?

--
nosy: +barry, pitrou

___
Python tracker 

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

[issue7507] pipes.quote does not correctly escape !

[Ben Gertzfield]

New submission from Ben Gertzfield :

The undocumented (but unit tested!) pipes.quote does not correctly 
escape '!', which cannot be passed to the shell outside of single-
quotes:

sh-3.2$ python
Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pipes
>>> pipes.quote("omgshoes!")
'omgshoes!'

sh-3.2$ echo "omgshoes!"
sh: !": event not found

bash-3.2$ echo "omgshoes!"
bash: !": event not found

zsh-4.3.9% echo "omgshoes!"
dquote> 

This needs to be single-quoted for safety:

sh-3.2$ echo 'omgshoes!'
omgshoes!
bash-3.2$ echo 'omgshoes!'
omgshoes!
zsh-4.3.9% echo 'omgshoes!'
omgshoes!

--
components: Library (Lib)
messages: 96405
nosy: bgertzfield, eric.smith, jjwiseman, tim_one
severity: normal
status: open
title: pipes.quote does not correctly escape !
type: behavior
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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Antoine Pitrou]

Antoine Pitrou  added the comment:

As I said, a flexible solution would be for thread creation functions to
take an optional argument specifying whether to block signals or not.
(I don't mind the default value of the argument :-))

--

___
Python tracker 

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

[issue4770] binascii module, crazy error messages, unexpected behavior

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

The email interface ate part of the code snippet. Here's the complete
version:

>>> import base64
>>> base64.b64decode('äöü'.encode('raw-unicode-escape'))
b''
>>> base64.b64decode('äöü'.encode('ascii'))
Traceback (most recent call last):
  File "", line 1, in 
UnicodeEncodeError: 'ascii' codec can't encode characters in position
0-2: ordinal not in range(128)

--

___
Python tracker 

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

[issue7502] All DocTestCase instances compare and hash equal to each other

[Antoine Pitrou]

Antoine Pitrou  added the comment:

There doesn't seem to be an __eq__ or __cmp__ method in DocTestCase,
which implies that the issue is with unittest.TestCase (from which
DocTestCase inherits).

--
nosy: +michael.foord, pitrou
priority:  -> normal
stage:  -> needs patch
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

[issue7471] GZipFile.readline too slow

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ah, a patch. Now we're talking :)

--
resolution: wont fix -> 
stage:  -> patch review
status: closed -> open
versions: +Python 2.7, Python 3.2 -Python 2.6

___
Python tracker 

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

[issue7502] All DocTestCase instances compare and hash equal to each other

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

Or an interaction between TestCase and DocTestCase.  TestCase.__eq__ and
TestCase.__hash__ are both implemented in terms of the _testMethodName
attribute.  It looks like this is *always* "runTest" for a DocTestCase
instance.  It probably doesn't make sense to set a _testMethodName for
DocTestCase instances (maybe it doesn't even make sense for DocTestCase
to subclass TestCase, in fact).  So perhaps overriding comparison and
hashing to use the attributes that do make sense (_dt_test, maybe, I
don't know) would make sense.

--

___
Python tracker 

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

[issue7502] All DocTestCase instances compare and hash equal to each other

[Michael Foord]

Michael Foord  added the comment:

Agreed, defining __eq__ and __hash__ on DocTestCase sounds like the way
to go.

--

___
Python tracker 

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

[issue7471] GZipFile.readline too slow

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The patch doesn't apply against the SVN trunk (some parts are rejected).
I suppose it was done against 2.6 or earlier, but those versions are in
bug fixing-only mode (which excludes performance improvements), so
you'll have to regenerate it against the SVN trunk.

(for info about our SVN repository, see
http://www.python.org/dev/faq/#how-do-i-get-a-checkout-of-the-repository-read-only-and-read-write
)

--

___
Python tracker 

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

[issue7471] GZipFile.readline too slow

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ah, my bad, I hadn't seen that the patch is for 3.2. Sorry for the
confusion.

--

___
Python tracker 

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

[issue4770] binascii module, crazy error messages, unexpected behavior

[flox]

flox  added the comment:

I perform a "grep" on the email package (with patch applied).
There's some places where 'raw-unicode-escape' is used.

I understand that all "payload.encode('raw-unicode-escape')" should be
changed to "payload.encode('ascii')" when the payload is processed by
another transfer encoding (line 202, 207 and 214).
The last one (when 'content-transfer-encoding' is not recognized) should
remain unchanged?

All other uses of 'raw-unicode-escape' seem correct.



Lib/email/base64mime.py:112:
return a2b_base64(string.encode('raw-unicode-escape'))
Lib/email/header.py:111:
word = bytes(word, 'raw-unicode-escape')
Lib/email/message.py:202:
payload = payload.encode('raw-unicode-escape')
Lib/email/message.py:207:
payload = payload.encode('raw-unicode-escape')
Lib/email/message.py:214:
in_file = BytesIO(payload.encode('raw-unicode-escape'))
Lib/email/message.py:225:
return payload.encode('raw-unicode-escape')
Lib/email/message.py:767:
as_bytes = charset[2].encode('raw-unicode-escape')
Lib/email/utils.py:298:
rawbytes = bytes(text, 'raw-unicode-escape')

--

___
Python tracker 

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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Adam Olsen]

Adam Olsen  added the comment:

A better solution would be to block all signals by default, then unblock
specific ones you expect.  This avoids races (as undeliverable signals
are simply deferred.)

Note that readline is not threadsafe anyway, so it doesn't necessarily
need to allow calls from the non-main thread.  Maybe somebody is using
that way, dunno.

--

___
Python tracker 

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

[issue7471] GZipFile.readline too slow

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I confirm that the patch gives good speedups. It would be nice if there
was a comment explaining what extrabuf, extrastart and extrasize are.

In 3.x, a better but more involved approached would be to rewrite the
gzip module so as to take advantage of the standard IO classes
(especially BufferedReader / BufferedWriter), which are written in C and
are therefore much faster.

--

___
Python tracker 

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

[issue7498] test_multiprocessing test_rapid_restart fails if port 9999 already in use

[R. David Murray]

R. David Murray  added the comment:

Committed in r76840 on trunk, r76842 for 2.6, r76843 for py3k, and
r76844 for 3.1.

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

___
Python tracker 

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

[issue4770] binascii module, crazy error messages, unexpected behavior

[flox]

flox  added the comment:

Patch updated:
 * Added documentation
 * Switched to "payload.encode('ascii')" in the "email.message" module

Note: there was no ambiguity on the first line of the documentation:
« [These functions] convert between binary and various ASCII-encoded
binary representations »

So, it should only convert bytes in range(256) to bytes in range(128).

--
Added file: http://bugs.python.org/file15562/issue4770_binascii_py3k_v2.diff

___
Python tracker 

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

[issue4770] binascii module, crazy error messages, unexpected behavior

[flox]

Changes by flox :


Removed file: http://bugs.python.org/file15562/issue4770_binascii_py3k_v2.diff

___
Python tracker 

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

[issue4770] binascii module, crazy error messages, unexpected behavior

[flox]

Changes by flox :


Added file: http://bugs.python.org/file15563/issue4770_binascii_py3k_v2.diff

___
Python tracker 

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

[issue7508] Update 'file object' doc

[Terry J. Reedy]

New submission from Terry J. Reedy :

"5.9. File Objects¶
File objects are implemented using C’s stdio package and can be created
with the built-in open() function."

As I understand, the part about stdio is no longer true.
Also, as I understand, there is no longer a class  object.
Rather there are various io (or _io) classes returned by open depending
on the args, especially the mode. This should be made clear. Something like

"File objects are created by the built-in open function and others.
There are instances of various classes exposed in the io module. The
following discusses the methods common to various file objects."

Maybe even retitle the section "IO objects" and use 'io' instead of
'file' as the prefix for method names.

Maybe whoever wrote the new io system could check this section for accuracy.

--
assignee: georg.brandl
components: Documentation
messages: 96419
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Update 'file object' doc
versions: 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

[issue7509] AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root'

[Sridhar Ratnakumar]

New submission from Sridhar Ratnakumar :

This error happened while installing pycrypto 2.0.1 on XP 64-bit with VS 
2008 express installed using Python 2.6.4 64-bit (via buildout).

Getting distribution for 'pycrypto>=1.9'.
Traceback (most recent call last):
  File "", line 1, in 
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
1714, in main
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
1695, in with_ei_usage
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
1718, in 
  File "C:\Python25\lib\distutils\core.py", line 151, in setup
dist.run_commands()
  File "C:\Python25\lib\distutils\dist.py", line 974, in run_commands
self.run_command(cmd)
  File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
236, in run
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
452, in easy_install
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
501, in install_item
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
680, in install_eggs
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
957, in build_and_install
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
946, in run_setup
  File "build\bdist.win32\egg\setuptools\sandbox.py", line 29, in 
run_setup
  File "build\bdist.win32\egg\setuptools\sandbox.py", line 70, in run
  File "build\bdist.win32\egg\setuptools\sandbox.py", line 31, in 

  File "setup.py", line 163, in 

  File "C:\Python25\lib\distutils\core.py", line 151, in setup
dist.run_commands()
  File "C:\Python25\lib\distutils\dist.py", line 974, in run_commands
self.run_command(cmd)
  File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
  File "build\bdist.win32\egg\setuptools\command\bdist_egg.py", line 
174, in run
  File "build\bdist.win32\egg\setuptools\command\bdist_egg.py", line 
161, in call_command
  File "C:\Python25\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
  File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
  File "build\bdist.win32\egg\setuptools\command\install_lib.py", line 
20, in run
  File "C:\Python25\lib\distutils\command\install_lib.py", line 112, in 
build
self.run_command('build_ext')
  File "C:\Python25\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
  File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
  File "C:\Python25\lib\distutils\command\build_ext.py", line 299, in 
run
self.build_extensions()
  File "setup.py", line 116, in build_extensions

  File "C:\Python25\lib\distutils\command\build_ext.py", line 425, in 
build_extensions
self.build_extension(ext)
  File "C:\Python25\lib\distutils\command\build_ext.py", line 490, in 
build_extension
depends=ext.depends)
  File "C:\Python25\lib\distutils\msvccompiler.py", line 354, in compile
if not self.initialized: self.initialize()
  File "C:\Python25\lib\distutils\msvccompiler.py", line 264, in 
initialize
self.__paths = self.get_msvc_paths("path")
  File "C:\Python25\lib\distutils\msvccompiler.py", line 616, in 
get_msvc_paths
% (self.__root, self.__version))
AttributeError: MSVCCompiler instance has no attribute 
'_MSVCCompiler__root'
An error occured when trying to install pycrypto 2.0.1. Look above this 
message for any errors that were output by easy_
install.
While:
  Installing python.
  Getting distribution for 'pycrypto>=1.9'.
Error: Couldn't install: pycrypto 2.0.1

--
assignee: tarek
components: Distutils
messages: 96420
nosy: srid, tarek
severity: normal
status: open
title: AttributeError: MSVCCompiler instance has no attribute 
'_MSVCCompiler__root'
type: behavior
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

[issue7510] AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root'

[Sridhar Ratnakumar]

New submission from Sridhar Ratnakumar :

This error happened while installing pycrypto 2.0.1 on XP 64-bit with VS 
2008 express installed using Python 2.5.4 64-bit (via buildout).

See also: http://twistedmatrix.com/trac/ticket/3352

Getting distribution for 'pycrypto>=1.9'.
Traceback (most recent call last):
  File "", line 1, in 
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
1714, in main
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
1695, in with_ei_usage
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
1718, in 
  File "C:\Python25\lib\distutils\core.py", line 151, in setup
dist.run_commands()
  File "C:\Python25\lib\distutils\dist.py", line 974, in run_commands
self.run_command(cmd)
  File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
236, in run
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
452, in easy_install
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
501, in install_item
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
680, in install_eggs
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
957, in build_and_install
  File "build\bdist.win32\egg\setuptools\command\easy_install.py", line 
946, in run_setup
  File "build\bdist.win32\egg\setuptools\sandbox.py", line 29, in 
run_setup
  File "build\bdist.win32\egg\setuptools\sandbox.py", line 70, in run
  File "build\bdist.win32\egg\setuptools\sandbox.py", line 31, in 

  File "setup.py", line 163, in 

  File "C:\Python25\lib\distutils\core.py", line 151, in setup
dist.run_commands()
  File "C:\Python25\lib\distutils\dist.py", line 974, in run_commands
self.run_command(cmd)
  File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
  File "build\bdist.win32\egg\setuptools\command\bdist_egg.py", line 
174, in run
  File "build\bdist.win32\egg\setuptools\command\bdist_egg.py", line 
161, in call_command
  File "C:\Python25\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
  File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
  File "build\bdist.win32\egg\setuptools\command\install_lib.py", line 
20, in run
  File "C:\Python25\lib\distutils\command\install_lib.py", line 112, in 
build
self.run_command('build_ext')
  File "C:\Python25\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
  File "C:\Python25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
  File "C:\Python25\lib\distutils\command\build_ext.py", line 299, in 
run
self.build_extensions()
  File "setup.py", line 116, in build_extensions

  File "C:\Python25\lib\distutils\command\build_ext.py", line 425, in 
build_extensions
self.build_extension(ext)
  File "C:\Python25\lib\distutils\command\build_ext.py", line 490, in 
build_extension
depends=ext.depends)
  File "C:\Python25\lib\distutils\msvccompiler.py", line 354, in compile
if not self.initialized: self.initialize()
  File "C:\Python25\lib\distutils\msvccompiler.py", line 264, in 
initialize
self.__paths = self.get_msvc_paths("path")
  File "C:\Python25\lib\distutils\msvccompiler.py", line 616, in 
get_msvc_paths
% (self.__root, self.__version))
AttributeError: MSVCCompiler instance has no attribute 
'_MSVCCompiler__root'
An error occured when trying to install pycrypto 2.0.1. Look above this 
message for any errors that were output by easy_
install.
While:
  Installing python.
  Getting distribution for 'pycrypto>=1.9'.
Error: Couldn't install: pycrypto 2.0.1

--
assignee: tarek
components: Distutils
messages: 96421
nosy: srid, tarek
severity: normal
status: open
title: AttributeError: MSVCCompiler instance has no attribute 
'_MSVCCompiler__root'
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

[issue7511] msvc9compiler.py: ValueError: [u'path']

[Sridhar Ratnakumar]

New submission from Sridhar Ratnakumar :

Win XP 64-bit
Python 2.6.4 64-bit

Getting distribution for 'pycrypto>=1.9'.
Traceback (most recent call last):
  File "", line 1, in 
  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 1714, in main

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 1695, in with_ei_usage

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 1718, in 

  File "C:\Python26\lib\distutils\core.py", line 152, in setup
dist.run_commands()
  File "C:\Python26\lib\distutils\dist.py", line 975, in run_commands
self.run_command(cmd)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
cmd_obj.run()
  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 236, in run

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 452, in easy_install

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 501, in install_item

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 680, in install_eggs

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 957, in build_and_install

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 946, in run_setup

  File "build\bdist.win-amd64\egg\setuptools\sandbox.py", line 29, in 
run_setup
  File "build\bdist.win-amd64\egg\setuptools\sandbox.py", line 70, in 
run
  File "build\bdist.win-amd64\egg\setuptools\sandbox.py", line 31, in 

  File "setup.py", line 163, in 

  File "C:\Python26\lib\distutils\core.py", line 152, in setup
dist.run_commands()
  File "C:\Python26\lib\distutils\dist.py", line 975, in run_commands
self.run_command(cmd)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
cmd_obj.run()
  File "build\bdist.win-amd64\egg\setuptools\command\bdist_egg.py", line 
174, in run
  File "build\bdist.win-amd64\egg\setuptools\command\bdist_egg.py", line 
161, in call_command
  File "C:\Python26\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
cmd_obj.run()
  File "build\bdist.win-amd64\egg\setuptools\command\install_lib.py", 
line 20, in run
  File "C:\Python26\lib\distutils\command\install_lib.py", line 113, in 
build
self.run_command('build_ext')
  File "C:\Python26\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
cmd_obj.run()
  File "C:\Python26\lib\distutils\command\build_ext.py", line 340, in 
run
self.build_extensions()
  File "setup.py", line 116, in build_extensions

  File "C:\Python26\lib\distutils\command\build_ext.py", line 449, in 
build_extensions
self.build_extension(ext)
  File "C:\Python26\lib\distutils\command\build_ext.py", line 499, in 
build_extension
depends=ext.depends)
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 448, in 
compile
self.initialize()
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 358, in 
initialize
vc_env = query_vcvarsall(VERSION, plat_spec)
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 274, in 
query_vcvarsall
raise ValueError(str(list(result.keys(
ValueError: [u'path']
An error occured when trying to install pycrypto 2.0.1. Look above this 
message for any errors that were output by easy_
install.
While:
  Installing python.
  Getting distribution for 'pycrypto>=1.9'.
Error: Couldn't install: pycrypto 2.0.1

--
assignee: tarek
components: Distutils
messages: 96422
nosy: srid, tarek
severity: normal
status: open
title: msvc9compiler.py: ValueError: [u'path']
type: behavior
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

[issue7509] AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root'

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

Duplicate of issue7510

--
status: open -> closed

___
Python tracker 

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

[issue7510] AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root'

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Python 2.5 is no longer maintained, except for security issues (which
this one is not). Closing as won't fix.

--
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue7511] msvc9compiler.py: ValueError: [u'path']

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Most likely, the problem is that visual studio is not installed on your
system.

--
nosy: +loewis

___
Python tracker 

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

[issue7511] msvc9compiler.py: ValueError: [u'path']

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

I have Visual C++ 2008 express edition installed.

Maybe it is a quirk of express edition as I was able to install pycrypto 
fine with the Visual Studio 2008 professional edition at work machine.

In any case, I believe this is a bug with distutils.

--

___
Python tracker 

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

[issue7512] shutil.copystat may fail EOPNOTSUPP

[Kuang-che Wu]

New submission from Kuang-che Wu :

"flags" is only supported on certain OS. FreeBSD is one of them.
FreeBSD itself support chflags but not all of its file systems do.

On FreeBSD, copystat() will fail on zfs. The exception is OSError and
errno is EOPNOTSUPP. According to manpage chflags(2), the errno means
"The underlying file system does not support file flags"

If the file system doesn't support flags, we should not call
os.chflags() at first or should not raise exception.

In my patch, I just ignore EOPNOTSUPP exception.

--
components: Library (Lib)
files: copystat.diff
keywords: patch
messages: 96427
nosy: kcwu
severity: normal
status: open
title: shutil.copystat may fail EOPNOTSUPP
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15564/copystat.diff

___
Python tracker 

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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Andriy Pylypenko]

Andriy Pylypenko  added the comment:

Let me add my 2 cents. I understood the considerations about differences 
between Python code level interrupt handling and OS level interrupts. 

What I cannot get is why to preserve the handling of signals in the user 
threads on OSes like FreeBSD and Solaris. This functionality isn't used 
on Linux and Windows at all, as the interrupts on them are always 
delivered to the main thread. The patch simply assures the same behavior 
on the FreeBSD and Solaris, so why to keep things unpredictable when 
there is a way to solve the problem? Can anyone state what exactly 
purpose of not to make OS signal handling in Python predictable?

This bug report was created mainly because there is no easy Python code 
solution for this problem. The Python documentation clearly states that 
there is no user accessible Python functions that can modify per-thread 
signal mask, so it is currently impossible to solve the problem with 
just Python code. Modification of timeouts isn't vital solution in far 
too many real life situations.

BTW this patch is officially in the FreeBSD ports tree since Feb 27 2009 
and there is no complains on this patch since then.

--

___
Python tracker 

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