[issue2538] memoryview of bytes is not readonly

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

This patch looks good.

One question: in Objects/abstract.c in PyBuffer_FillInfo, why is it even
testing for the PyBUF_LOCK flag at all?  PEP 3118 says its valid for
both reading and writing (if the underlying object supports locked access).

BTW, I is someone is going to merge any py3k buffer api related changes
back into the backport that is in 2.6?

__
Tracker <[EMAIL PROTECTED]>

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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Tarek Ziadé]

Tarek Ziadé <[EMAIL PROTECTED]> added the comment:

ok, I'll summarize this in distutils-sig sometime today.

If we do use Unicode, I think we might need an extra meta-data,
"encoding", that would default to "utf8", and that could be used when
the class needs to serialize the data in a file.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Tarek Ziadé]

Tarek Ziadé <[EMAIL PROTECTED]> added the comment:

adding a sample patch to show a possible implementation, and to point
the problem to people

Added file: http://bugs.python.org/file9967/unicode.metadata.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2569] default_scheme in urlparse.urlparse() useless

[pk]

New submission from pk <[EMAIL PROTECTED]>:

Hello,

the urlparse() function accepts a parameter default_scheme, to be used
if the address given does not contain one, but I cannot make
use of it, because I would expect these two returning
identical values:

>>> from urlparse import urlparse
>>> urlparse("www","http")
('http', '', 'www', '', '', '')
>>> urlparse("http://www","http";)
('http', 'www', '', '', '', '')

This has been reported about six years ago but apparently
the behaviour hasn't changed.  I cannot imagine that this
really is the intended behaviour.

Regards,

pk

--
components: Library (Lib)
messages: 65071
nosy: pk
severity: normal
status: open
title: default_scheme in urlparse.urlparse() useless
type: behavior
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2569] default_scheme in urlparse.urlparse() useless

[pk]

pk <[EMAIL PROTECTED]> added the comment:

and this is the url to the old report:

http://mail.python.org/pipermail/python-list/2002-August/157171.html

__
Tracker <[EMAIL PROTECTED]>

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

[issue2128] sys.argv is wrong for unicode strings

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Martin, you are right that they are not from the same reason as that issue.

gcc -c -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk/ 
-fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes 
-I. -IInclude -I./Include   -DPy_BUILD_CORE -o Modules/main.o Modules/main.c
Modules/main.c: In function 'Py_Main':
Modules/main.c:478: warning: passing argument 1 of 'Py_SetProgramName'
from incompatible pointer type
Modules/main.c: In function 'Py_Main':
Modules/main.c:478: warning: passing argument 1 of 'Py_SetProgramName'
from incompatible pointer type

__
Tracker <[EMAIL PROTECTED]>

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

[issue1232947] non-admin install may fail (win xp pro)

[Mark Hammond]

Mark Hammond <[EMAIL PROTECTED]> added the comment:

I can repro this too using python-2.6a2.msi - after selecting "just for
me" on XP running as a non-admin user, I see an error message regarding
permissions.  On vista, I get an elevation prompt (and if I hit "allow",
installation proceeds as if I had selected 'for all users' - ie,
HKLM\Python is written, rather than HKCU, shortcuts are written to "all
users" folder, uninstall requires elevation)

I'm attaching the log after canceling installation at the elevation
prompt under Vista.

--
nosy: +mhammond
Added file: http://bugs.python.org/file9968/python.log

_
Tracker <[EMAIL PROTECTED]>

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

[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

I don't like that the patch changes the API of a function in
test_support() (in particular changing the return type; adding optional
arguments is not a problem).  This could trip up 3rd party users of this
API.  I recommend creating a new API bind_host_and_port() (or whatever
you'd like to name it) and implement the original API in terms of the
new one.  (You can even add a warning if you think the original API is
always unsafe.)

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Marc-Andre Lemburg]

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:

Note that 

value = unicode(value).encode("utf-8")

will also work if value is already Unicode, so a backwards compatible
fix would be to allow passing in:

 * ASCII encoded strings
 * Unicode objects

for the meta data keyword parameters and then apply unicode() to all the
meta-data arguments.

I don't think that we should support non-ASCII encodings for meta-data 
strings passed to setup().

If setuptools is broken in this respect, it needs to be fixed. Dito for
other 3rd party tools.

--
nosy: +lemburg

__
Tracker <[EMAIL PROTECTED]>

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

[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix

[Trent Nelson]

Trent Nelson <[EMAIL PROTECTED]> added the comment:

To be honest, I wasn't really happy either with having to return HOST, 
it's somewhat redundant given that all these tests should be binding 
against localhost.  What about something like this for bind_port():

def bind_port(sock, host=''):
"""Bind the socket to a free port and return the port number.
Relies on ephemeral ports in order to ensure we are using an
unbound port.  This is important as many tests may be running
simultaneously, especially in a buildbot environment."""

# Use a temporary socket object to ensure we're not 
# affected by any socket options that have already 
# been set on the 'sock' object we're passed. 
tempsock = socket.socket(sock.family, sock.type)
tempsock.bind((host, 0))
port = tempsock.getsockname()[1]
tempsock.close()
del tempsock

sock.bind((host, port))
return port

The tests would then look something like:

HOST = 'localhost'
PORT = None

class Foo(TestCase):
def setUp(self):
sock = socket.socket()
global PORT
PORT = test_support.bind_port(sock, HOST)

So, the return value is the port bound to, no change there, but we're 
abolishing preferred_port as an optional argument, which is important, 
IMO, as none of these tests should be stipulating which port they want 
to listen on.  That's actually the root of this entire problem.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

Thanks, that's much better (though I'm not the authority on all details
of this patch).

__
Tracker <[EMAIL PROTECTED]>

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

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

I think we should either get this into the 3.0a5 release planned for May
7, or wait for 3.1.  I'd prefer to see some kind of PEP discussion on
the python-3000 list, rather than just a BDFL approval in a tracker
issue.  I think it's a useful feature (especially now we already have
PEP 3132) but we're getting close to the release, so I'd like to see
some more eyeballs on this code...  I expect the PEP discussion will be
short and sweet -- either most folks like it, or we should not push
through at this point in time.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2159] dbmmodule inquiry function is performance prohibitive

[Jesús Cea Avión]

Jesús Cea Avión <[EMAIL PROTECTED]> added the comment:

Somebody posted a similar issue in pybsddb. The patch I proposed would
be consistent with current "__len__" *internal* use, but the real
intention, I think, is to return True or False if the database is open
or closed, not if the database is empty or not.

Opinions?

See http://mailman.argo.es/pipermail/pybsddb/2008-April/28.html

__
Tracker <[EMAIL PROTECTED]>

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

[issue2159] dbmmodule inquiry function is performance prohibitive

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

Assigning anything not related to Py3k design to me is a mistake; I
don't have the bandwidth to handle this, sorry.

--
assignee: gvanrossum -> 

__
Tracker <[EMAIL PROTECTED]>

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

[issue508157] urllib.urlopen results.readline is slow

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

Please don't add to a closed issue that old.  If you still have an issue
with this, please open a new issue.  If you have a patch, kindly upload
it to the issue.


Tracker <[EMAIL PROTECTED]>


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

[issue2541] Unicode escape sequences not parsed in raw strings.

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

To be honest, I don't know what the uses are for that codec.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2541] Unicode escape sequences not parsed in raw strings.

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

pickle still uses it when protocol=0 (and cPickle as well, but in trunk/
only of course)

__
Tracker <[EMAIL PROTECTED]>

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

[issue2547] Py30a4 RELNOTES only cover 30a1 and 30a2

[Barry A. Warsaw]

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:

Setting this to release blocker so I can't forget it for the next alphas.

--
priority:  -> release blocker

__
Tracker <[EMAIL PROTECTED]>

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

[issue2292] Missing *-unpacking generalizations

[Thomas Wouters]

Thomas Wouters <[EMAIL PROTECTED]> added the comment:

Agreed. A PEP was already on my TODO list (although I don't mind if
someone else picks it up :-) I implemented the
dict-unpacking-in-dict-literal syntax in the mean time; it's pushed to
the starunpack bzr branch, but I'll add some actual tests before I
upload the patch.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

Hm, can you use lowercase for the local variable names dststart and
dstend? Otherwise looks good.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2557] \u and \U in raw strings have regressed in 3.0a4

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

We went over this before.  *I* consider the 2.x behavior a mistake, and
a decision was made to change in 3.0.  It got much worse in 3.0 because
all literals are Unicode (except byte literals).

To add a unicode value to a raw string, just concatenate a raw string
and a non-raw string, e.g.

r'whatever' '\u1234' r'whatever'

I don't understand what you meant by '\x1234' -- the \x escape only
accepts 2 hex digits.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2547] Py30a4 RELNOTES only cover 30a1 and 30a2

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

Barry, this sounds like a file you weren't aware of.  Too late for
3.0a4, but perhaps you can add this to the roster of files to be looked
at for each release?

--
assignee: gvanrossum -> barry
nosy: +barry

__
Tracker <[EMAIL PROTECTED]>

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

[issue2570] backport 3.0-style \u/\U processing in raw strings when unicode_literals is imported from __future__

[Guido van Rossum]

New submission from Guido van Rossum <[EMAIL PROTECTED]>:

In 3.0, r'\u1234' is a string of 6 characters (\, u, 1, 2, 3, 4).  In
2.6, after "from __future__ import unicode_literals" it is a string of
one character (code point 0x1234).  IMO the 3.0 behavior should be
imported from the future as well (using the same import).

--
components: Interpreter Core
keywords: 26backport
messages: 65090
nosy: gvanrossum
severity: normal
status: open
title: backport 3.0-style \u/\U processing in raw strings when unicode_literals 
is imported from __future__
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

[Daniel Diniz]

Daniel Diniz <[EMAIL PROTECTED]> added the comment:

Changed the local dststart, dstend variables to lowercase, "dates" to
"times" (in "find start and end times") and the diff was created from
trunk/ this time (as opposed to trunk/Doc/includes/).

Added file: http://bugs.python.org/file9969/tzinfo-examples4.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

Thanks, looks good. Since this is assigned to Georg, can you check it
in, Georg?

Should this be backported to 2.5 docs as well?

__
Tracker <[EMAIL PROTECTED]>

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

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Committed as r62214, r62215 (2.5).

--
resolution:  -> accepted
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue2571] cmd.py always uses raw_input, even when another stdin is specified

[Richard King]

New submission from Richard King <[EMAIL PROTECTED]>:

The module global value use_rawinput is initialized to 1 but not reset
when stdin is replaced with a passed-in value.

--
components: Extension Modules
messages: 65094
nosy: rickbking
severity: normal
status: open
title: cmd.py always uses raw_input, even when another stdin is specified
type: behavior
versions: Python 2.4

__
Tracker <[EMAIL PROTECTED]>

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

[issue2292] Missing *-unpacking generalizations

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

Thomas,

Could you add BUILD_*_UNPACK opcodes documentation to
Doc/library/dis.rst?   It would also help if you modify CALL_FUNCTION_*
opcodes' documentation to explain how they will interact with unpacking
opcodes.

Do I understand correctly that non-starred arguments are packed into
intermediate tuples/sets in the presence of starred arguments so that
{a,b,*c,d,e} is equivalent to {*{a,b},*c,*{d,e}}? This should not be a
problem for tuples, but with sets, it means that {a,b,c} may behave
subtly differently from {a,*(b,c)}.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

>  Do I understand correctly that non-starred arguments are packed into
>  intermediate tuples/sets in the presence of starred arguments so that
>  {a,b,*c,d,e} is equivalent to {*{a,b},*c,*{d,e}}? This should not be a
>  problem for tuples, but with sets, it means that {a,b,c} may behave
>  subtly differently from {a,*(b,c)}.

Can you show an example where this would be different?

__
Tracker <[EMAIL PROTECTED]>

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

[issue2567] Section "New-style and classic classes" needs to be removed/rewritten

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Fixed in r62216.

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2572] 3.0 pickle docs -- what about old-style classes?

[Georg Brandl]

New submission from Georg Brandl <[EMAIL PROTECTED]>:

Can 3.0 unpickle pickled old-style classes? Which pickling methods are
supported? Etc.

--
assignee: alexandre.vassalotti
components: Documentation
messages: 65098
nosy: alexandre.vassalotti, georg.brandl
severity: normal
status: open
title: 3.0 pickle docs -- what about old-style classes?
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue2292] Missing *-unpacking generalizations

[Thomas Wouters]

Thomas Wouters <[EMAIL PROTECTED]> added the comment:

On Mon, Apr 7, 2008 at 9:00 PM, Alexander Belopolsky <[EMAIL PROTECTED]>
wrote:

>
> Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
>
> Thomas,
>
> Could you add BUILD_*_UNPACK opcodes documentation to
> Doc/library/dis.rst?   It would also help if you modify CALL_FUNCTION_*
> opcodes' documentation to explain how they will interact with unpacking
> opcodes.

They don't interact. They're separate opcodes. The CALL_FUNCTION_* opcodes
are almost untouched, except the _VAR and _VAR_KW versions: previously, they
expected, on the stack, positional arguments followed by keyword/argument
pairs followed by the *args sequence followed by the **kwargs mapping (for
_VAR_KW.) I just changed the order so *args is before the keyword/argument
pairs. The change is not related to the BUILD_*_UNPACK opcodes, but rather
to Guido's request that the order of keyword arguments and *args in the
functioncall syntax changes. For the order of execution to remain sane, the
arguments need to be pushed on the stack in that order, and keeping the
_VAR* opcode order the same would mean a large amount of ROT_* opcodes ;-P

Updating the docs is on the TODO list.

>
> Do I understand correctly that non-starred arguments are packed into
> intermediate tuples/sets in the presence of starred arguments so that
> {a,b,*c,d,e} is equivalent to {*{a,b},*c,*{d,e}}? This should not be a
> problem for tuples, but with sets, it means that {a,b,c} may behave
> subtly differently from {a,*(b,c)}.
>

Yes, that's what happens, but only in the presence of *args. For
functioncalls, it only happens to everything after the first *args
(inclusive.) That means '{a, b, c}' does not change, and neither does
'func(a, b, c)' or 'func(a, b, *c)'. As for sets, I don't see why this would
be a problem; there is no difference in the set created by {a, b, c} and the
set created by {a, *{b, c}} or {a, *(b, c)}.  The arguments are all
evaluated in the same order (left to right), and c replaces b, b replaces a
if they are considered equal by sets.

Added file: http://bugs.python.org/file9970/unnamed

__
Tracker <[EMAIL PROTECTED]>

__On Mon, Apr 7, 2008 at 9:00 PM, Alexander 
Belopolsky [EMAIL PROTECTED]> 
wrote:

Alexander Belopolsky [EMAIL 
PROTECTED]> added the comment:

Thomas,

Could you add BUILD_*_UNPACK opcodes documentation to
Doc/library/dis.rst?   It would also help if you modify CALL_FUNCTION_*
opcodes' documentation to explain how they will interact with unpacking
opcodes.They don't interact. They're separate 
opcodes. The CALL_FUNCTION_* opcodes are almost untouched, except the _VAR and 
_VAR_KW versions: previously, they expected, on the stack, positional arguments 
followed by keyword/argument pairs followed by the *args sequence followed by 
the **kwargs mapping (for _VAR_KW.) I just changed the order so *args is before 
the keyword/argument pairs. The change is not related to the BUILD_*_UNPACK 
opcodes, but rather to Guido's request that the order of keyword arguments 
and *args in the functioncall syntax changes. For the order of execution to 
remain sane, the arguments need to be pushed on the stack in that order, and 
keeping the _VAR* opcode order the same would mean a large amount of ROT_* 
opcodes ;-P
Updating the docs is on the TODO list.

Do I understand correctly that non-starred arguments are packed into
intermediate tuples/sets in the presence of starred arguments so that
{a,b,*c,d,e} is equivalent to {*{a,b},*c,*{d,e}}? This should not be a
problem for tuples, but with sets, it means that {a,b,c} may behave
subtly differently from {a,*(b,c)}.
Yes, 
that's what happens, but only in the presence of *args. For functioncalls, 
it only happens to everything after the first *args (inclusive.) That means 
'{a, b, c}' does not change, and neither does 'func(a, b, c)' 
or 'func(a, b, *c)'. As for sets, I don't see why this would be a 
problem; there is no difference in the set created by {a, b, c} and the set 
created by {a, *{b, c}} or {a, *(b, c)}.  The arguments are all evaluated 
in the same order (left to right), and c replaces b, b replaces a if they are 
considered equal by sets.
-- Thomas Wouters [EMAIL PROTECTED]>Hi! I'm a .signature virus! 
copy me into your .signature file to help me spread!
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Thomas Wouters]

Changes by Thomas Wouters <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file9970/unnamed

__
Tracker <[EMAIL PROTECTED]>

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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> If we do use Unicode, I think we might need an extra meta-data,
> "encoding", that would default to "utf8", and that could be used when
> the class needs to serialize the data in a file.

I don't think so. Whenever the data is written to a file, the file
format should specify the encoding.

Regards,
Martin

__
Tracker <[EMAIL PROTECTED]>

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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> I don't think that we should support non-ASCII encodings for meta-data 
> strings passed to setup().
> 
> If setuptools is broken in this respect, it needs to be fixed. Dito for
> other 3rd party tools.

We do need to support non-ASCII files, as distutils didn't previously
even support Unicode strings, and people still wanted to get their names
right. It's not about setuptools, and not about other 3rd party tools.
It's about distutils packages which we need to continue to support.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2568] Seconds range in time unit

[Anton Fedorov]

Anton Fedorov <[EMAIL PROTECTED]> added the comment:

There no leap second in 2000th.
But correct time request fails:
>>> datetime.strptime('19951231T235960', '%Y%m%dT%H%M%S')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: second must be in 0..59

__
Tracker <[EMAIL PROTECTED]>

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

[issue2573] Can't change the framework name on OS X builds

[Aaron Gallagher]

New submission from Aaron Gallagher <[EMAIL PROTECTED]>:

There is currently no way in the configure script to specify an 
alternate name for Python.framework. If I want to completely separate 
versions of Python (e.g. for 3.0 alphas and/or Stackless), I have to 
manually edit configure.in and configure to change the framework name. 
It would be much more convenient if --with-framework could take an 
optional parameter of the framework name to use.

--
components: Build, Macintosh
messages: 65105
nosy: habnabit
severity: normal
status: open
title: Can't change the framework name on OS X builds
type: feature request
versions: Python 2.6, Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue1232947] non-admin install may fail (win xp pro)

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> I can repro this too using python-2.6a2.msi - after selecting "just for
> me" on XP running as a non-admin user, I see an error message regarding
> permissions.

I think this is mixing up entirely unrelated issues. 2.6a2 is known to
require admin privileges; see the caveat on the release page.

_
Tracker <[EMAIL PROTECTED]>

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

[issue2571] cmd.py always uses raw_input, even when another stdin is specified

[Daniel Diniz]

Daniel Diniz <[EMAIL PROTECTED]> added the comment:

I don't think it should stop using raw_input just because you changed
stdin, as you can change it to something that will work with raw_input.
Consider:
>>> import sys
>>> sys.stdin = open("/dev/tty")
>>> raw_input()
a
'a'

You can tie it to any object (e.g. a GUI input) that supports the file
protocol and keep using raw_input. Or change Cmd.use_rawinput to 0 to
use stdin.readline directly.

On a related issue. Cmd.use_rawinput should be "True", not 1...

--
nosy: +ajaksu2

__
Tracker <[EMAIL PROTECTED]>

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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Marc-Andre Lemburg]

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:

Agreed, but any change will target the package authors who can easily
upgrade their packages to use Unicode for e.g. names.

If the change were to address distutils users, we'd have to be a lot
more careful.

In any case, if UTF-8 is the defacto standard used in older packages,
then we should probably use that as fallback solution if the ASCII
assumption doesn't work out:

try:
value = unicode(value)
except UnicodeDecodeError:
value = unicode(value, 'utf-8')
value = value.encode('utf-8')

__
Tracker <[EMAIL PROTECTED]>

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

[issue2568] Seconds range in time unit

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

OP does not have the reference, but the issue is apparently in the time
and datetime modules documentation:

http://docs.python.org/dev/library/time.html#time.strftime
http://docs.python.org/dev/library/datetime.html#strftime-behavior

Note that datetime's doc is twice incorrect because leap seconds are not
supported by the datetime module at all:

>>> from datetime import *
>>> time(23,59,60)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: second must be in 0..59
>>> datetime.strptime('2101T235960', '%Y%m%dT%H%M%S')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: second must be in 0..59

--
assignee:  -> georg.brandl
components: +Documentation -Library (Lib)
nosy: +belopolsky, georg.brandl

__
Tracker <[EMAIL PROTECTED]>

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

[issue2292] Missing *-unpacking generalizations

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

On Mon, Apr 7, 2008 at 3:07 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

>  Can you show an example where this would be different?

Admittedly a contrived example, but

...def __hash__(self):
...print('hash', self)
...return int.__hash__(self)
...
>>> a,b,c = map(X, range(3))
>>> {a,b,c}
hash 2
hash 1
hash 0
{0, 1, 2}
>>> {a,*(b,c)}
hash 0
hash 1
hash 2
{0, 1, 2}

__
Tracker <[EMAIL PROTECTED]>

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

[issue2292] Missing *-unpacking generalizations

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

I missed the first line copying the class definition into my previous
post.  Class 'X' was defined as follows:

class X(int):
def __hash__(self):
print('hash', self)
return int.__hash__(self)

__
Tracker <[EMAIL PROTECTED]>

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

[issue2292] Missing *-unpacking generalizations

[Thomas Wouters]

Thomas Wouters <[EMAIL PROTECTED]> added the comment:

I'm not sure how this matters. The order of evaluation is the same, the
BUILD_SET implementation just hashes the evaluated items in a different
order. You can't really rely on that particular order as it's tied
closely to the stack representation CPython uses. I also see no
practical reason -- or even practical *way* -- to abuse the hashing
order. But you have given me an idea on how to improve some of the code
in the BUILD_*_UNPACK opcodes, hmm.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2568] Seconds range in time unit

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

On the other hand, the time module allows full [00,61] range:

>>> [time.strftime('%S',time.strptime(x, '%S')) for x in ('00', '61')] 
['00', '61']

so this is implementation rather than documentation issue.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2568] Seconds range in time unit

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

On Mon, Apr 7, 2008 at 3:42 PM, Anton Fedorov <[EMAIL PROTECTED]> wrote:

>  There no leap second in 2000th.

I was just too lazy too look up the leap second year, but datetime
module knows nothing about leap seconds, so I did not expect different
behavior for years 1995 and 2000.

>  But correct time request fails:
>  >>> datetime.strptime('19951231T235960', '%Y%m%dT%H%M%S')

ditto

__
Tracker <[EMAIL PROTECTED]>

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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> Agreed, but any change will target the package authors who can easily
> upgrade their packages to use Unicode for e.g. names.

They can't: that would break their 2.5-and-earlier compatibility.

> If the change were to address distutils users, we'd have to be a lot
> more careful.

We do address distutils users: what else? Why should we be more careful?

> In any case, if UTF-8 is the defacto standard used in older packages,
> then we should probably use that as fallback solution if the ASCII
> assumption doesn't work out:
> 
> try:
> value = unicode(value)
> except UnicodeDecodeError:
> value = unicode(value, 'utf-8')
> value = value.encode('utf-8')

For writing the metadata, we don't need to make any assumptions. We
can just write the bytes as-is. This is how distutils has behaved
for many releases now, and this is how users have been using it.

Of course, we (probably) agree that this is conceptually wrong, as
we won't be able to know what the encoding of the metadata file is,
and we (probably) also agree that the metadata should have the
fixed encoding of UTF-8. However, I don't think we should deliberately
break packages before 3.0 (even if they chose to use some other
encoding); instead, such packages will silently start doing the
right thing with 3.0, when their strings become Unicode strings.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1232947] non-admin install may fail (win xp pro)

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

I'm closing this as "won't fix". I don't really see a way to support
this kind of setup (i.e. the start menu is on a network drive to which
the installer service cannot write).

--
resolution:  -> wont fix
status: open -> closed

_
Tracker <[EMAIL PROTECTED]>

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

[issue2574] Add RFC 3768 SSM Multicast support to "socket"

[bms]

New submission from bms <[EMAIL PROTECTED]>:

Hi,

Here is a patch to add RFC 3768 SSM Multicast support to low-level
Python socket module as of 2.5.1.

I have not tested the setsourcefilter()/getsourcefilter() socket member
functions other than compiling the patch on a Gentoo Linux 2008.0 box
w/2.6 Linux kernel.

These APIs should be fairly portable. Note that I haven't added any
other configure glue, like the rest of socket, support is very low level
and getting the arguments to struct.pack() right is the user's problem.

cheers
BMS

--
components: Extension Modules
files: python-2.5.1-multicast-ssm.patch
keywords: patch
messages: 65115
nosy: bms
severity: normal
status: open
title: Add RFC 3768 SSM Multicast support to "socket"
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file9971/python-2.5.1-multicast-ssm.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

I agree with Thomas.  The order in which __hash__() is evaluated
shouldn't matter to your app; if __hash__() isn't a pure function (apart
from possible caching) you've got worse trouble.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2292] Missing *-unpacking generalizations

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

On Mon, Apr 7, 2008 at 4:02 PM, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> .. The order of evaluation is the same, the
>  BUILD_SET implementation just hashes the evaluated items in a different
>  order. You can't really rely on that particular order as it's tied
>  closely to the stack representation CPython uses.

I agree and that's why I said the difference in behavior is "subtle"
and my example is "contrived."   However, I believe Raymond expressed
a similar concern in msg63065.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.

[Marc-Andre Lemburg]

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:

With "distutils users" I'm referring to people that are told to run
"python setup.py install". Changed affecting the way this line behaves
need to be carefully considered.

OTOH, when upgrading a package to a new Python version (and distutils
version), package authors will have to modify their packages anyway, so
it is well possible to ask them to use Unicode strings for meta-information.

Supporting pre-2.6 Python version is also not much of a problem, since
authors could setup the strings in question to be either Unicode or
8-bit strings depending on the Python version.

This change would be really minor (compared to e.g the Py_ssize_t change
;-).

That said, I don't think it's a good idea to make package data more
complicated by allowing multiple encodings. The meta-data file should
have a fixed pre-defined encoding, preferrably UTF-8.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2575] Reference manual: production for integer literals is missing "bininteger"

[Mark Dickinson]

New submission from Mark Dickinson <[EMAIL PROTECTED]>:

The production list for integer literals is missing the `bininteger`
term for binary integer literals.  Patch attached.

--
assignee: georg.brandl
components: Documentation
files: bininteger.diff
keywords: patch, patch
messages: 65119
nosy: georg.brandl, marketdickinson
severity: normal
status: open
title: Reference manual: production for integer literals is missing "bininteger"
versions: Python 3.0
Added file: http://bugs.python.org/file9972/bininteger.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2571] cmd.py always uses raw_input, even when another stdin is specified

[Raghuram Devarakonda]

Raghuram Devarakonda <[EMAIL PROTECTED]> added the comment:

The doc for "cmd" at
http://docs.python.org/dev/library/cmd.html#module-cmd says:

"Instances of Cmd subclasses have some public instance variables:
.
.
.
Cmd.use_rawinput¶
A flag, defaulting to true. If true, cmdloop() uses raw_input() to
display a prompt and read the next command; if false, sys.stdout.write()
and sys.stdin.readline() are used. (This means that by importing
readline, on systems that support it, the interpreter will automatically
support Emacs-like line editing and command-history keystrokes.)"

So it is for the user to modify use_rawinput as required. This flag has
been introduced in #405952. BTW, this one and other similar variables
are at class level and are not instance variables. Isn't it?

--
nosy: +draghuram

__
Tracker <[EMAIL PROTECTED]>

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

[issue2576] httplib read() very slow due to lack of socket buffer

[Aren Olson]

New submission from Aren Olson <[EMAIL PROTECTED]>:

This is a reposting of issue 508157, as requested by gvanrossum.

The socket file object in httplib is opened without any buffering
resulting in very slow performance of read().  The specific problem is
in the httplib.HTTPResponse constructor.  It calls sock.makefile() with
a 0 for the buffer size.  changing the buffer size to 4096 improved the
time needed to download 10MB from 15.5s to 1.78s, almost 9x faster.
Repeat downloads of the same file (meaning the server now has the file
cached in memory), yield times of 15.5s and 0.03s, a 500x improvement.
When fetching from a server on the local network, rather than from
localhost, these times become 15.5s and 0.9s in both cases, a 17x
speedup. Real-world situations will likely be a mix of these, however it
is safe to say the speed improvement will be substantial. Adding an
option to adjust the buffer size would be very welcome, though the
default value should still be zero, to avoid the issues already
mentioned in issue 508157.

These speed results were obtained with python2.5 and apache2 under
Ubuntu linux, using the code found here: http://pastebin.ca/973578

--
components: Library (Lib)
messages: 65121
nosy: reacocard
severity: normal
status: open
title: httplib read() very slow due to lack of socket buffer
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue2576] httplib read() very slow due to lack of socket buffer

[Gregory P. Smith]

Changes by Gregory P. Smith <[EMAIL PROTECTED]>:


--
priority:  -> high

__
Tracker <[EMAIL PROTECTED]>

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

[issue2574] Add RFC 3768 SSM Multicast support to "socket"

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Can you submit a patch against the trunk? There aren't going to be any
new features in 2.5.

--
nosy: +benjamin.peterson

__
Tracker <[EMAIL PROTECTED]>

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

[issue2292] Missing *-unpacking generalizations

[Thomas Wouters]

Thomas Wouters <[EMAIL PROTECTED]> added the comment:

I don't think the order in which the items are hashed is really what
Raymond was worried about. Rather, the size of the stack was, and the
effect of having all the items on the stack at the same time. I think
Raymond is wrong in this case; while the stack may grow relatively big,
we're only talking two pointers here. The items will all have to be
created anyway, and in the usual case the number of duplicate keys is low. 

My patch actually includes pretty much the same change to BUILD_MAP,
because it greatly simplifies the compiler code and gets rid of a lot of
extra opcodes -- causing an overal speedup even in the face of large
dict literals. But I guess we should take it up with Raymond at some
point, perhaps as part of the PEP discussion.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2573] Can't change the framework name on OS X builds

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Would you like to work on a patch?

--
nosy: +benjamin.peterson

__
Tracker <[EMAIL PROTECTED]>

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

[issue2572] 3.0 pickle docs -- what about old-style classes?

[Alexandre Vassalotti]

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment:

Python 3.0 shouldn't have any problem unpickling old-style classes.
However, they will be unpickled as new-style classes. Therefore, there
might be a few corner-cases that might cause some problems. For example,
if an old-style class contains a __slots__:

Python 2.5.1 (r251:54863, Mar  7 2008, 04:10:12) 
>>> import pickle
>>> class A:
...   __slots__ = []
... 
>>> pickle.dumps(A())
'(i__main__\nA\np0\n(dp1\nb.'

Python 3.0a3+ (py3k:62050M, Mar 30 2008, 17:29:33) 
>>> class A:
...   __slots__ = []
... 
>>> pickle.loads(b'(i__main__\nA\np0\n(dp1\nb.')
Traceback (most recent call last):
  ...
TypeError: __class__ assignment: '_EmptyClass' deallocator differs from 'A'

__
Tracker <[EMAIL PROTECTED]>

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

[issue2576] httplib read() very slow due to lack of socket buffer

[Daniel Diniz]

Daniel Diniz <[EMAIL PROTECTED]> added the comment:

The code patch is trivial. I believe it needs docs (both explaining how
to use and warning against the problems it may cause), a NEWS entry and
tests (at least to check what happens when an invalid value lands).

I can work on those changes if the general idea is not shot down :)

--
keywords: +patch
nosy: +ajaksu2
Added file: http://bugs.python.org/file9973/httplib.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2577] cmd.py should track input file objects so macros with submacros can be easily written

[Richard King]

New submission from Richard King <[EMAIL PROTECTED]>:

Add an "input" method or property that saves the current input file
object and resets the input file object; when input results in an "EOF",
the input file object stack is popped and reading continues from there.
A modified cmd.py is attached.

--
components: Extension Modules
files: cmd.py
messages: 65128
nosy: rickbking
severity: normal
status: open
title: cmd.py should track input file objects so macros with submacros can be 
easily written
type: feature request
versions: Python 2.4
Added file: http://bugs.python.org/file9974/cmd.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue2240] setitimer, getitimer wrapper

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

Trent Nelson kindly gave me access to his FreeBSD 6.2 buildbot so I had
chance to do some tests. The problem happens when Python is built
against or libc_r, or if you are using libmap you won't need to
recompile but the problem still happens when using libc_r.

I started searching in the FreeBSD bug tracker and found this issue:
http://www.freebsd.org/cgi/query-pr.cgi?pr=threads/49087 which seems
very similar to the problem related here.

I've also done a very simple "test" in C, just to demonstrate that this
issue isn't related to Python at all:

#include 
#include 
#include 

void h(int signo)
{
struct itimerval t;

getitimer(ITIMER_PROF, &t);
printf("%d %d\n", t.it_value.tv_sec, t.it_value.tv_usec);

printf("deactive ITIMER_PROF\n");
t.it_value.tv_sec = 0;
t.it_value.tv_usec = 0;
setitimer(ITIMER_PROF, &t, &t);
}

int main(void)
{
struct itimerval ival;

ival.it_value.tv_sec = 1;
ival.it_value.tv_usec = 0;
ival.it_interval.tv_sec = 1;
ival.it_interval.tv_usec = 0;

signal(SIGPROF, h);
printf("%d\n", setitimer(ITIMER_PROF, &ival, NULL));
alarm(2);

while (1) {
getitimer(ITIMER_PROF, &ival);
if (ival.it_value.tv_sec == 0 && ival.it_value.tv_usec == 0)
break;
}

return 0;
}

When I compile this using -lc_r then the callback "h" is never called
and then the alarm is fired. Compiling against pthread, thr or nothing
(since this example doesn't need any threading library) doesn't
demonstrate this problem and all is fine (callback "h" is invoked,
infinite loop finishes and test returns 0).

Should further discussion be moved to python-dev ? I'm somewhat stuck on
how to resolve this, besides saying to upgrade to FreeBSD 7 which uses
libthr by default.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1179] [CVE-2007-4965] Integer overflow in imageop module

[David Remahl]

David Remahl <[EMAIL PROTECTED]> added the comment:

Uploading patch that addresses the test cases above. It applies on top of 
nevyn’s latest patch.

Added file: http://bugs.python.org/file9975/python-2.5-int-overflow-2.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1736190] asyncore/asynchat patches

[Guido van Rossum]

Changes by Guido van Rossum <[EMAIL PROTECTED]>:


_
Tracker <[EMAIL PROTECTED]>

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

[issue2182] tokenize: does not allow CR for a newline

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

I don't think this ought to be changed in exec().  It ought to be done
by opening the file using universal newlines.

--
resolution:  -> rejected
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue2578] Figure out what to do with unittest's redundant APIs

[Benjamin Peterson]

New submission from Benjamin Peterson <[EMAIL PROTECTED]>:

unittest has many redundant APIs (eg. failIf and assertFalse) which can
be phased out in 3.x. We may also want to change the actually methods so
they really do what they say:

if x == y:
   pass
 else:
   raise AssertionError(...)

rather than

 if x != y:
   raise AssertionError(...)

--
components: Library (Lib)
messages: 65132
nosy: benjamin.peterson
severity: normal
status: open
title: Figure out what to do with unittest's redundant APIs
type: feature request
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue2182] tokenize: does not allow CR for a newline

[Jared Grubb]

Jared Grubb <[EMAIL PROTECTED]> added the comment:

This is not a report on a bug in exec(), but rather a bug in the
tokenize module -- the behavior between the CPython tokenizer and the
tokenize module is not consistent. If you look in the tokenize.py
source, it contains code to recognize both \n and \r\n as newlines, but
it ignores the possibility that \r could be the line ending character
(as the Python reference says).

__
Tracker <[EMAIL PROTECTED]>

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

[issue2579] Misleading 'toctree references unknown document' error

[Henry]

New submission from Henry <[EMAIL PROTECTED]>:

The 'toctree references unknown document' can be misleading when the
document name includes whitespace.

For example, I had mistakenly created an index file of the form

.. toctree::
   :maxdepth: 2

overview

(note that overview has a leading space). In the error message is was
very difficult to see that this was a problem, as the error message was

WARNING: /home/henry/code/bdec.docs/doc/source/index.rst:8: (WARNING/2)
toctree references unknown document  overview

By putting the document name in quotes, it becomes clearer what the
problem was.

WARNING: /home/henry/code/bdec.docs/doc/source/index.rst:8: (WARNING/2)
toctree references unknown document ' overview'

A patch to include these quotes has been attached.

--
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: unknown_reference.patch
keywords: patch
messages: 65134
nosy: georg.brandl, henryl
severity: normal
status: open
title: Misleading 'toctree references unknown document' error
Added file: http://bugs.python.org/file9976/unknown_reference.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2577] cmd.py should track input file objects so macros with submacros can be easily written

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

You should include a diff, not the entire file with your changes

--
nosy: +gpolo

__
Tracker <[EMAIL PROTECTED]>

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

[issue2573] Can't change the framework name on OS X builds

[Aaron Gallagher]

Aaron Gallagher <[EMAIL PROTECTED]> added the comment:

Here's a framework that implements the necessary change. I'm not very good 
at autoconf, so it might need to be touched up.

--
keywords: +patch
Added file: http://bugs.python.org/file9977/framework.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2580] Revise builtin class int library manual entry

[Terry J. Reedy]

New submission from Terry J. Reedy <[EMAIL PROTECTED]>:

Based on c.l.p discussion with Mark Dickinson, who supplied details and
corrections, we propose the following for the int() entry at
http://docs.python.org/dev/3.0/library/functions.html#int

int([number | string[, radix]])
Convert a number or string to an integer.  If no arguments are given,
return 0.  If a number is given, return number.__int__().  Conversion of
floating point numbers to integers truncates towards zero.  A string
must be a base-radix integer literal optionally preceded by '+' or '-'
(with no  space in between) and optionally surrounded by whitespace.  A
base-n literal consists of the digits 0 to n-1, with 'a' to 'z' (or 'A'
to 'Z')having values 10 to 35.  The default radix is 10. The allowed
values are 0 and 2-36.  Base-2, -8, and -16 literals can  be optionally
prefixed with 0b/0B, 0o/0O, or 0x/0X, as with integer literals in code.
 Radix 0 means to interpret exactly as a code literal, so that the
actual radix is 2, 8, 10, or 16, and so that int('010',0) is not legal,
while int('010') is.

The revised signature makes it clear from the start that *radix* can
only follow *string*, so no sentence to that effect is needed in the
text.  The other changes are to discuss the signature in order and to
add details.  We believe the above accurately reflects the
intended/actual behavior once the no-space-after-sign patch is applied.
 (I don't know if that made it into .0a4).

Some of this might apply to the 2.6 docs, except that the no-space patch
will apparently not be backported.  I believe the acceptable strings are
a bit different also, at least for octals, but I am not sure.

--
assignee: georg.brandl
components: Documentation
messages: 65137
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Revise builtin class int library manual entry
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue2573] Can't change the framework name on OS X builds

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
assignee:  -> ronaldoussoren
nosy: +ronaldoussoren

__
Tracker <[EMAIL PROTECTED]>

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

[issue2577] cmd.py should track input file objects so macros with submacros can be easily written

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Also, please make it against the current trunk.

--
nosy: +benjamin.peterson

__
Tracker <[EMAIL PROTECTED]>

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

[issue2581] Vista UAC/elevation support for bdist_wininst

[Mark Hammond]

New submission from Mark Hammond <[EMAIL PROTECTED]>:

The attached patch adds basic UAC support to bdist_wininst created
installers.  A new option '--user-access-control' has been added to
bdist_wininst, which is written to the INI file read by the installer. 
The installer reads this value: if it is 'force', elevation is always
requested, if it is 'auto', elevation is requested when Python is
installed in HKLM.  'none' (the default) means nothing UAC related
happens at all.

The elevation happens by having the installer re-execute itself using
ShellExecute.

I've also ensured the code builds for all versions of VS we support.  As
a result, it was necessary to change the old bdist_wininst project files
to point to the later zlib version Python itself uses.  All these
changes are in the patch.

--
assignee: mhammond
components: Distutils
files: bdist_wininst_uac.patch
keywords: patch, patch
messages: 65139
nosy: mhammond, theller
severity: normal
status: open
title: Vista UAC/elevation support for bdist_wininst
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9978/bdist_wininst_uac.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2574] Add RFC 3768 SSM Multicast support to "socket"

[bms]

bms <[EMAIL PROTECTED]> added the comment:

Benjamin Peterson wrote:
> Benjamin Peterson <[EMAIL PROTECTED]> added the comment:
>
> Can you submit a patch against the trunk? There aren't going to be any
> new features in 2.5.
>   

Would a patch against 2.6a2 be OK?

I have had a lot of problems building Python on Gentoo Linux (where I 
developed these patches) w/o using their ebuild system, so I am trying 
to keep things simple.

This stuff isn't really new as such, it's been in Windows, OpenSolaris 
and other OSes for a while now -- and trying to get FreeBSD SSM support 
out the door. I can understand if folk don't want to incorporate it in 
the production releases which most people are using, though, however 
it's still important that it sees the light of day.

Unfortunately the setsourcefilter() APIs are not terribly accessible to 
non C users such as Python without the wrapping, otherwise we end up 
instantiating arrays like we have to for fcntl.ioctl().

Also the plat-linux2 stuff seems to be lagging w.r.t the glibc inet 
defines in IN.py, where much of this stuff would normally appear.

cheers
BMS

__
Tracker <[EMAIL PROTECTED]>

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

[issue2574] Add RFC 3768 SSM Multicast support to "socket"

[bms]

bms <[EMAIL PROTECTED]> added the comment:

Bruce M Simpson wrote:
> Benjamin Peterson wrote:
>> Benjamin Peterson <[EMAIL PROTECTED]> added the comment:
>>
>> Can you submit a patch against the trunk? There aren't going to be any
>> new features in 2.5.
>>   
>
> Would a patch against 2.6a2 be OK?
>
> I have had a lot of problems building Python on Gentoo Linux (where I 
> developed these patches) w/o using their ebuild system, so I am trying 
> to keep things simple. 

I just tried to build python 2.6a2 from svn trunk in FreeBSD 
6.3-RELEASE. I get the same error messages as I do in Gentoo Linux:

%%%
Could not find platform independent libraries 
Consider setting $PYTHONHOME to [:]
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in 
import sys, os, imp, re, optparse
ImportError: No module named os
gmake: *** [sharedmods] Error 1
Exit 2
%%%

I have no PYTHON* variables set in my environment.

On Gentoo, when I build using the ebuild / emerge system, I don't see 
this issue, nor do I see it with FreeBSD ports. Obviously they are doing 
something which differs from the instructions in the README, and it 
makes it difficult for me to submit patches for versions of Python other 
than those supported by the packaging systems, as I am sure you can 
understand.

cheers
BMS

__
Tracker <[EMAIL PROTECTED]>

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

[issue2578] Figure out what to do with unittest's redundant APIs

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

My plan:
- add deprecations to 3.1
- remove in 3.3

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue2182] tokenize: does not allow CR for a newline

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

I still think it shouldn't be tokenize's business to handle this.  I'm
not quite sure how exec() manages to do this; I note that this gives a
syntax error:

exec('x = 1\rprint x\r')

__
Tracker <[EMAIL PROTECTED]>

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

[issue2240] setitimer, getitimer wrapper

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> Should further discussion be moved to python-dev ? I'm somewhat stuck on
> how to resolve this, besides saying to upgrade to FreeBSD 7 which uses
> libthr by default.

Discussing on python-dev is fine. An acceptable solution would be to
omit setitimer/getitimer on FreeBSD if the FreeBSD version is "wrong",
either at configure time or at compile time. An even better solution
would be to test at configure time whether these functions work, and
refuse to expose them if they don't (not sure whether that's possible,
though, as I don't know when the choice of threading library is made).

__
Tracker <[EMAIL PROTECTED]>

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

[issue2578] Figure out what to do with unittest's redundant APIs

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

In a separate bug report, Steve Purcell indicated that he was taking 
the module in the opposite direction and adding more redundancy in an 
effort to fully match the J-Unit API.

--
assignee:  -> purcell
nosy: +purcell, rhettinger

__
Tracker <[EMAIL PROTECTED]>

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

[issue2578] Figure out what to do with unittest's redundant APIs

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

I'm all for adding new APIs that provide new functionality (we have a
few at Google that we really should contribute).

I'm not for having several aliases for the same functionality; it maybe
the JUnit way but Python's unittest.py is not JUnit not does it strive
for 100% JUnit compatibility -- the languages just are to different.

What's the bug# for Steve's proposal?

__
Tracker <[EMAIL PROTECTED]>

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

[issue2573] Can't change the framework name on OS X builds

[Ronald Oussoren]

Ronald Oussoren <[EMAIL PROTECTED]> added the comment:

To start: thanks for the patch.

I haven't done a detailed review yet, I have a minor nit: could you 
change  Mac/Makefile.in as well, specifically the definition:

PYTHONAPPSDIR=/Applications/MacPython $(VERSION)

This is used to install a number of GUI applications. "MacPython" should 
be replaced by the framework name. That will drop the "Mac" prefix in a 
default install, but that's not a problem and possibly confusing anyway.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2578] Figure out what to do with unittest's redundant APIs

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

See http://bugs.python.org/issue2249 for discussion.

Personally, I prefer minimalism and would like the API thinned 
considerably.  Also, I don't think all of the classes should be 
exposed.  AFAICT, nobody cares about test suite objects, test result 
objects, and test loader objects.  These are really artifiacts of an 
implementation originally designed to demonstrate how a unittest suite 
could be implemented.   

In Kent Beck's book on Test Driven Development, he complains that most 
unittest implementations spawned from his original work have grown far 
too complicated and would be better served by sticking to a simple 
framework for writing and running tests.

Some of that may have been lost in a effort to model J-Unit or to 
expose all the parts in support of people who want to use subclassing 
to write their own unittest variants and extensions (I have seen this 
in practice but it is somewhat rare). 

If making big changes to the unittest API is on the table, it is worth 
considering alternatives like py.test which is more powerful, easier to 
learn, much less verbose, and more in line with the way python is 
usually written.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2573] Can't change the framework name on OS X builds

[Aaron Gallagher]

Aaron Gallagher <[EMAIL PROTECTED]> added the comment:

Okay, here's the same patch but now with Mac/Makefile.in patched. I 
changed all references to Python to the framework name, because I believe 
it won't work properly otherwise.

Added file: http://bugs.python.org/file9979/framework2.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2578] Figure out what to do with unittest's redundant APIs

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

Agreed that the various loader classes etc. are mostly a waste.  The sad
thing is that everyone who is serious about unittests has to reinvent
the code that finds files ending in _test.py on the filesystem, or
something like that, since that's *not* supported directly.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2182] tokenize: does not allow CR for a newline

[Jared Grubb]

Jared Grubb <[EMAIL PROTECTED]> added the comment:

Yes, but exec(string) also gives a syntax error for \r\n:

exec('x=1\r\nprint x') 

The only explanation I could find for ONLY permitting \n as newlines in
 exec(string) comes from PEP278: "There is no support for universal
newlines in strings passed to eval() or exec. It is envisioned that such
strings always have the standard \n line feed, if the strings come from
a file that file can be read with universal newlines." (This is why my
original example had to be exec(file) and not just a simple exec(string))

Of the 3 newline types, exec(*) allows 1 or all 3 as the case may be,
and tokenize allows exactly 2 of them. I honestly am not sure what the
"right" way is (or should be), but either way, the tokenize module is
not consistent with exec.

(By the way, if you're curious why I filed this issue and Issue#2180,
I'm working on the PyPy project to help improve its current Python
lexer/parser. In order to ensure that it is correct and robust, I was
experimenting with corner cases in Python syntax and I found these cases
where tokenize disagrees with exec.)

__
Tracker <[EMAIL PROTECTED]>

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

[issue2182] tokenize: does not allow CR for a newline

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

I recommend that you only care about \n and consider everything else
unspecified.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2182] tokenize: does not allow CR for a newline

[Jared Grubb]

Jared Grubb <[EMAIL PROTECTED]> added the comment:

I actually hadnt thought of that. PyPy should actually use universal
newlines to its advantage; after all, it IS written in Python... Thanks
for the suggestion!

In any case, I wanted to get this bug about the standard library in your
record, in case you wanted to handle it. It is fairly innocuous, so I'll
let it go. Take care.

__
Tracker <[EMAIL PROTECTED]>

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